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(57) Abstract 

Computerized methods and tools for developing and 
implementing economic policies are provided. The methods 
and tools may include the use of an adaptive knowledge 
base for assisting in the formulation of policies and the use 
of a computerized financial market trading system for the 
implementation of those policies. The tools are suitable for 
implementation using a wide range of computer hardware, 
including personal computers (PCs) and mainframe compu- 
ters. The methods and tools do not rely on advanced com- 
munication or financial market trading infrastructure. These 
tools will operate in a broad range of applications iri~both 
developing and developed economies. The method further 
includes the principal steps of preparing a privatization bu- 
siness plan (101), reviewing said plan by a Privatization 
Board (103), executing the plan (105), restructuring the en- 
terprise in accordance to the plan (107), submitting an appli- 
cation for certification of demonopolization to the Privatiza- 
tion Board (109), and receiving an effective demonopoliza- 
tion date drom the Privatization Board (111). 
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establish effective privatization date. 
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PATENT APPLICATION 
for 

METHODS AND TOOLS FO R rOMPlTTCTI?Pr » 
SUPPORT OF A MAPKET ECONOMY 



FIELD OF THE INVENTION 
The present invention is generally related to the fields of information technology and 
market economics. The invention is more particularly related to computerized tools and 
methods useful for achieving a successful market economy. Yet more particularly, the 
present invention is related to tools and methods useful for privatizing, or transferring from 
state ownership to individual ownership, large state enterprises in newly democratic nations. 



BACKGROUND OF THE INVENTION 
Among the many tasks necessary to create a successful new world order, after the 
events of the past several years in Eastern Europe and the former Soviet Union, it will be 
necessary to transfer ownership rights in substantial portions of some countries' vast 
state-owned capital stock into private hands. In such countries, as well as others currently 
lacking effective owner shares markets, it may be desirable to develop policies and tools for 
operating such owner shares markets. Methods, tools and tasks necessary to accomplish 
such an enormous economic undertaking, -without causing socially destructive economic 
dislocation is the subject of intense current research. A detailed description of the economic 
background in which the present invention was developed is contained in Hartnett, William 
J., "Social Welfare and the Privatization of Large State Enterprises in Newly Democratic 
nations," incorporated herein by reference, and available from the Barker Engineering 
Library of the Massachusetts Institute of Technology as Thesis, C.E., 1993, M.S., by 
author and title. Hartnett, a draft (1992) of which forms British Provisional Patent 
Specification GB 9222884.0, filed October 30, 1992, also contains detailed descriptions of 
aspects of specific embodiments of the invention. Relevant portions thereof have been 
included herein as Appendices A, B and D. 

It is a general goal of the present invention to provide computerized market tools 



usable in countries which may be lacking market infrastructure. It is a more specific goal 
of the present invention to make available computerized market tools able to support any 
privatization policy chosen by government policy makers, including making possible the 
universal distribution policy outlined in Appendix A. 

SUMMARY OF THE INVENTION 

The present invention includes a computerized method of operating a market system, 
comprising the steps of: providing a computerized knowledge base incorporated in a 
computer system by which the knowledge base may be modified responsive to user 
evaluations and user contributions; formulating market system policies and parameters in 
accordance with contents of the knowledge base after any modifications made by the 
computer system to the computerized knowledge base; and on a digital computer, executing 
instructions to consummate market transactions by performing cross-price resolution, 
according to the policies formulated after any modifications to the computerized knowledge 
base. 

In a variation on the invention, the present invention may further include steps of 
receiving transaction orders, including portfolio trading delegation orders; and executing 
trading delegation orders for which cross-price resolution converges, resulting in 
delegator/delegatee assignments by which a delegator's portfolio is managed by a delegates 

In a further variation, the invention may include collecting and entering transaction 
orders into a computer system at a first level of a receiving hierarchy; combining the 
collected and entered transaction orders into a transaction file, by executing instructions on 
the computer system; writing the transaction file to at least one physical medium; and 
sending the physical medium to a second level of the receiving hierarchy. 

Another variation on the invention may include steps of collecting and entering 
transaction orders into a computer system at a first level of a receiving hierarchy; combining 



the collected and entered transaction orders into a transaction file; and 

transmitting the transaction file to a second level of a receiving hierarchy over an electronic 

communication network. 

In yet another variation, the invention may include a step of receiving orders 
transmitted electronically by individual users. 

The above variations may be combined to form additional variations on the present 
invention. Additional aspects of the present invention will become apparent to those skilled 
in the art, on reading the following description. 

BRIEF DESCRIPTION OF THE nRAWlMfi 
Like reference numerals indicate like elements in the Figures, in which: 
Fig. 1 is an overview flow chart of the privatization process contemplated by the 
present invention; 

Fig. 2 is an organizational block diagram of the inventive privatization process and the 
tools for implementing the same; 

Fig. 3 is a flow chart of updating a policy knowledge base according to one aspect of 
the present invention; 

Fig. 4 is a concept map of the hierarchical structure of an initial knowledge data base 
for the privatization planner of the present invention; 

Fig. 5 is a flow diagram illustrating the formation of a transaction data base for use by 
the privatization implementation tool of the illustrated embodiment of the present invention; 

Fig. 6 is a flow diagram of a process for updating a transaction data base using the 
privatization implementation tool of the illustrated embodiment of the present invention; and 

Fig. 7 is a flow diagram of the logic of the privatization planner embodiment of the 
adaptive knowledge base tool of the present invention. 



LIST OF APPENDICES 

In order to enhance the clarity of the following details of the example embodiments 
are described in the attached appendices, wherein: 

Appendix A is Hartnett (1992), Part I, Chapters 5, 6 and 7; 

Appendix B is Hartnett (1992), Part II, Appendices 2-5; 

Appendix C is a detailed description of the Privatization PlannerT operation, 
commands and knowledge base adaptation method; 

Appendix D is Hartnett (1992), Part III, Appendices 1 - 7; and 

Appendix E is a description, including screen samples, of the application of the 
knowledge base system of the Privatization PlannerT to a sustainable development 
application. 

DETAILED DESCRIPTION 
The present invention will be better understood in view of the following description, 
read in connection with the figures. The following description relates primarily to an 
embodiment of the invention suitable for privatizing a large economy. However, this is 
merely an example, given for purposes of illustrating the principles of the invention, which 
may be practiced in a variety of other contexts, some of which are indicated at appropriate 
points in the discussion. Some details in the following discussion relate specifically to the 
embodiment disclosed in Hartnett (1992), but may be implemented differently, as seen for 
example in Hartnett (1993) or Appendix C, yet remain within the contemplation of the 
present invention. 

A basic process of privatization in accordance with the present invention is illustrated 
in Fig. 1 . Various steps in this process are supported by computerized tools, such as will 
be described below. In order to understand the inter-relationships between the computerized 
tools, it is first necessary to understand the privatization process contemplated by the present 



invention, though the invention is applicable to other processes, as well. 

Each enterprise to be privatized is to undergo a process substantially as shown in Fig. 
1. The enterprise leadership first prepares a privatization business plan (Fig. 1, Step 101). 
The plan should include such detailed information as the current productive capacity of the 
enterprise, the capital stock and labor force of the enterprise, a risk of claimed physical 
facilities, a demonopolization goal as explained below, a stock compensation plan for board, 
management and workers of the enterprise, and such other elements as would conventionally 
be included in a business plan. Subsequently, the privatization business plan is reviewed by 
a Privatization Board (Fig. 1, step 103). 

The Privatization Board has several options by which it may dispose of a privatization 
business plan. It may disapprove of the privatization business plan, along with reasons for 
that disapproval. The Privatization Board may approve of a privatization business plan, in 
whole or in part. The Privatization Board may negotiate with the enterprise regarding a 
privatization business plan which has been disapproved in whole or in part. Thus, the 
interaction between the enterprise leadership and the Privatization Board helps to ensure that 
viable privatization business plans are written and subsequently executed. 

Often, the privatization Board will find that a privatization business plan for one 
enterprise conflicts with a privatization business plan, current or published contemplated 
future operation of another enterprise. In such a case, the Privatization Board will resolve 
such inter-enterprise conflicts at the time of review of the privatization business plan. 

Finally, in the course of the Privatization Board Review, an effective privatization 
date 105 is established. Naturally, an effective privatization date is established only for 
privatization business plans which have been approved. 

On the effective privatization date 105, the enterprise begins to execute its 
privatization business plan. The stock compensation plans described in the privatization 
business plan are implemented. Periodic financial reporting requirements are enforced. 
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In accordance with the plans laid out in the privatization business plan, the enterprise 
begins restructuring (Fig. 1, step 107). The enterprise may also initiate new, private, 
spin-off enterprises. 

When the enterprise leadership has reason to believe that the goal for 
demonopolization set in the privatization business plan (Fig. 1, step 101) has been met, then 
the enterprise may submit an application for certification of demonopolization to the 
Privatization Board (Fig. 1, step 109). The Privatization Board again has the options of 
approving, disapproving, or negotiating changes to the application. When an application for 
certification of demonopolization has been approved, then the Privatization Board will 
establish an effective demonopolization date 111. 

On the effective demonopolization date, the compensation stock from the stock 
compensation plans initiated on the effective privatization date will vest. At this point, 
privatization may be considered complete (Fig. 1, step 113). 

The organizational block diagram of Fig. 2 indicates how the tasks of privatization are 
divided among the computerized tools which are to be used to implement privatization. The 
tasks are divided into substantially two groups: planning tasks and transactional tasks. 

Planning tasks include the establishment of policy, the formulation of plans, the 
setting of goals and dates, and the customization of the tools for supporting the transactional 
tasks. Supporting this aspect of privatization is the Privatization PUumerT computerized 
tool 102. Example screens and source code are included in Appendix B. Operation and 
commands are included in Appendix C. Research and analysis 203 is performed using this 
computerized tool, which adapts to changing conditions, as described below. This tool will 
enable a country's economic leadership to plan privatization policies including the 
establishment of property rights 205, the formulation of incomes policies 207, structuring 
the privatization sequence 209, establishing an oversight agency 21 1 and communications 
with and within that agency, and customization 213 of the Privatized computerized tool 
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215 for management of transaction tasks. 

The Privatize !T computerized tool 215 permits the economic leadership of a country 
to process transactions submitted by portfolio owners and delegatees of portfolio owners 
concerning the enterprises owned 217, support enterprise polled shareholder voting 219 and 
support auctions of other state property 221 . File definitions, asset types, transactions and 
commands are described in Appendix D. In performing these tasks, processing centers will 
generate transaction data bases 223, which are ultimately merged into a single transaction 
data base for processing. A central computer which processes the transaction data base 225 
generates reinvestment transactions 227, establishes valid delegations 229, selects between 
alternative transactions 231, calculates clearing prices 233 and transmits results to financial 
institutions 235. The assets permitted to be owned and transactions permitted to be 
performed 239, by portfolio owners and delegatees are determined during a customization 
process 213 performed by the economic leadership of the country using Privatization 
PlannerT. The customization process 213 is also used to establish parameter values 241 , 
such as the period over which transactions will be processed, called the investment cycle 
period. 

The described embodiments of the invention are contemplated as being implemented in 
a version of the C programming language. This choice yields a number of advantages. 
The C programming language is a subject of international standards. Therefore, it is 
suitable for use in various countries. Furthermore, it is extremely portable from one 
computer platform to another computer platform, without extensive re-coding of modules, 
except perhaps certain platform-dependent interface modules. Yet another advantage of 
using the C programming language is that compilers are currently available on most 
platforms which produce particularly efficient, fast code. This last advantage makes the 
invention suitable for implementation using PC hardware, when so desired. 

The Privatization PlannerT computerized tool is next described. The Privatization 



PlanneiT is a computerized collaborative knowledge base tool designed to support custom 
privatization of a country's enterprises. Of course, depending on the contents and 
organization of the initial knowledge base with which Privatization PlanneiT has been 
initiated, it could be used in any application where it is desired to form a knowledge base 
which grows and evolves based upon user evaluations and proposed contributions. One 
such initial knowledge base is illustrated in the concept map of Fig. 4. Examples of such 
suitable applications of adaptive knowledge bases include: the pursuit of sustainable 
development, as described in Appendix E; research into avoiding ethnic strife; movie rating 
systems used in video rental and sales stores; and a literary anthology for which authors are 
remunerated based on the popularity of their contributions. For example, the embodiment 
of the adaptive knowledge base invention in a tool to support the pursuit of sustainable 
development, designated as the Sustainable Development ServerT, is achieved by 
adapting the identifying contents of the welcome screen, relabeling the name of the tool and 
subsequent screen displays, and using the same general purpose commands to create a 
structure of topics and associated pages of information relating to sustainable development. 
See Appendix E, for examples of screen displays for the Sustainable Development 
ServerT tool. The documentation of Privatization PlannerT embodiment of the adaptive 
knowledge base aspect of the invention contained in Appendix C is transformed into 
documentation for the Sustainable Development ServeiT by replacing references to 
Privatization PlannerT with Sustainable Development ServerT, replacing "ntn" with 
"sds" and replacing the documentation of the Simulate command with a description of any 
adaptive knowledge base interface to any tool or tools developed to simulate issues relating 
to sustainable development. The embodiment of the adaptive knowledge base aspect of the 
invention in a tool to support research into the avoidance of ethnic strife, designated as the 
Ethnic Strife ServerT is achieved in a like fashion, and the associated documentation is 
transformed by inserting Ethnic Strife ServerT and "ess" where appropriate, and by 
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appropriate adjustments to the description of the Simulate command. It is specifically 
contemplated that users may or may not be charged fees based upon the amount and nature 
of their knowledge base access. Contributors may or may not be remunerated based on the 
quantity, ratings and longevity in the knowledge base of their contributions. 

The Privatization PlannerT tool is implemented as a software program running on 
either one or more individual portable or personal computers in the hands of individual 
users or user groups, or accessible on electronic networks, including a worldwide network 
such as Internet. Individual users possess copies of relevant portions of the knowledge base 
for use with their copy of the tool. See Interest command in Appendix C. The knowledge 
base of die Privatization PlannerT tool is modified and updated based on evaluations 
entered by users of the Privatization PlannerT tool. See Fig. 3. 

The user evaluation cycle illustrated in Fig. 3 begins with users evaluating and 
proposing contributions (step 301) to the topics, subtopics, pages and organization of the 
knowledge base segment in their possession. The segments are then integrated (step 303) by 
a knowledge base coordinator operating a copy of the Privatization PlannerT tool to form 
a complete knowledge base containing the integrated whole of the knowledge base segments 
previously possessed by the individual users. Next, the pages are scored by the 
Privatization PlannerT tool (step 305) in accordance with the method described in 
Appendix B. Page scores are compiled into subtopic scores (step 307) and subtopic scores 
are compiled into topic scores (step 309). Making decisions in accordance with the scores 
obtained in the previous steps, the Privatization PlannerT tool adjusts the content and 
organization of the knowledge base (step 31 1) as described in Appendix B. The adjustments 
are base upon some form of optimization of the scores obtained above. Finally, individual 
segments are generated and distributed in accordance with the user preferences (step 313). 

Users may customize their usage of the tool (see Customize command in Appendix 
C), and can effectively access even very large numbers of entries using sophisticated 



keyword techniques (see Keyword command in Appendix C), and by filtering and sorting 
entries using date, evaluations by other users, and evaluations of the user himself using 
either actual evaluations or estimates based on past correlations or anti-correlations with 
other users (see Order command in Appendix C). Privatization PlannerT also provides 
and interface to a simulation of the PrivatizefT computerized marketplace, allowing users 
to simulate portfolio transactions and asset prices using the methods contained in the 
PrivatizefT tool. See Simulate command, Appendix C. 

The Privatization PlannerT computerized tool permits distribution of segmented or 
partial knowledge data bases, based on individual preferences. The knowledge base may be 
distributed in whole or in part over a network or on such physical distribution media as 
diskettes and CD ROM. 

After each user of the knowledge base has entered comments and evaluations to their 
own satisfaction, the segment on which they are in possession is returned through the 
network or physical media distribution channel to a knowledge base coordinator. The 
knowledge base coordinator merges the knowledge bases of all users into a single large 
knowledge base on a regular basis. The results of the various users' evaluations of entries 
in the knowledge base are then used by the Privatization PlannerT adaptive mechanism to 
eliminate entries which are of insufficient interest or value to users. 

Although the adaptive function has been thus far described in connection with entries, 
or information content, the structure of the knowledge base is also subject to user 
evaluation. A knowledge base is organized into topics, which have both content and 
organization. Furthermore, evaluations are graded on both on quantity and quality. That 
is, an entry or topic organization evaluation consists of both the amount of information 
associated with that topic and the value of the evaluation given by each user. The scoring 
of the evaluations according to one embodiment of the present invention is discussed in 
detail in Appendix B. 
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PrhratizelT is a computerized tool to support free markets in newly democratic 
nations. The tool is capable of implementing any privatization policy chosen by government 
policy makers, and in particular includes a capability to support distribution of shares in 
large state enterprises to an entire citizenry. Universal distribution of at least a portion of 
public assets, such as large state enterprises, can completely avoid the need to value such 
assets prior to privatization. This is advantageous in developing economies without any 
adequate means of achieving such valuations. It is also advantageous in and applicable to 
developed economies because it can avoid the large absolute inefficiency associated with 
even a modest relative underwriting valuation error. Legislation or a decree can vest in 
each citizen privatization rights in the form of Stock Market Units (SMUs). SMUs are a 
way to aggregate rights to equity in state enterprises into a current private asset, by defining 
a new financial instrument composed of one share in each enterprise due to be privatized 
over a fixed interval. While normally the fixed interval will begin on or immediately after 
the date of legislation and terminate at some future date certain, it is also possible to define 
intervals which are completely in the past or which are completely in the more distant 
future. For example, if the main SMU were defined to extend from the date of legislation 
to the end of the subsequent year, then a SMU2 could be defined to begin at the termination 
of the fixed interval of the SMU and continue for an additional year or more. SMUs can be 
immediately and freely traded. In particular, a citizen's right to a SMU allocation can be 
used in bidding for small state enterprises at once, even before implementation of the entire 
system. The PrivatizelT tool solves the problem in newly democratic nations that a stock 
trading infrastructure must quickly be provided to execute market transactions in the absence 
of a significantly developed communication and financial intermediation infrastructure. 
Thus, it is a particular feature of PrhratizelT that the files and methods used may be 
efficiently implemented using minimum hardware and in the absence of an advanced 
infrastructure; For example, communications are contemplated as performed using physical 



transfers of information on diskettes, tapes or other physical media when sophisticated 
telecommunications happen to be lacking. Similarly, the market resolution methods are 
suitable for implementation on personal computers (PCs) as well as large mainframes. 

Other assets contemplated as being traded in accordance with the PrivatizefT 
embodiment of this aspect of the invention include stock or debt in specific enterprises, debt 
of governments or financial institutions, foreign currency, price level adjusted mortgages, in 
addition to flexibly specified annuities which are keyed to standardized actuarial tables and 
priced according to their implicit interest rate. This aspect of the present invention has 
many other useful applications. For example, assets such as natural resource rights in 
Bahrain, air pollution rights in the United States, or the proceeds of a South African wealth 
tax collected either in the form of money or "in kind" such as in the form of stock, could 
be vested in a very large number of recipients or an entire citizenry, and a marketplace with 
an extremely broad investment opportunity set provided by this system. Appropriate bids 
and offers for any available asset can be made by any entity with an account on the system, 
including governments, organizations and individuals. One objective of this aspect of the 
invention is to provide a "springboard" to free enterprise in the context of a free market. 

The tool also supports the creation of a "social security" account for each citizen, for 
example initially endowed with a supplemental allocation of Stock Market Units or newly 
privatized stock in individual enterprises by means of universal distribution. This can be a 
very attractive capability even in developed market economies where large state enterprises 
are to be privatized but policy makers wish to strengthen the social safety net in the process. 
The regulation of such social security accounts can specify that the Stock Mark Units in 
these accounts can only be exchanged for government debt, lifetime annuities or other 
specified assets, but with immediate distributions when necessitated by hardship. Such 
regulation of social security accounts is supported in the PrivatizelT tool. See, for 
example the Security transaction, Appendix D. Additional allocation of Stock Market Units 
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can be made to social welfare accounts of local governments in an amount corresponding to 
the number of citizens liable to be missed, for example due to homelessness. The result is a 
strengthening of the "safety net" for social welfare. 

PrivatizelT supports the market for enterprise shares in a variety of ways such as 
dividend payments, stock subscriptions and "going private." It also provides subsets of 
shareholder lists for shareholder votes based on polling techniques. An embedded 
marketplace for the delegation of authority to professional investment organizations at 
competitive rates is included in the PrivatizelT tool to facilitate efficient markets and price 
discovery. These features of the market tool are additional examples of capabilities which 
can be valuable in developing and developed economies alike. It is specifically 
contemplated that users of the PrivatizelT tool may or may not be charged fees based on 
the amount and nature of their usage of the system. 

The operation of the PrivatizelT tool is now described in connection with Figs. 5 and 

6. 

The investment cycle begins with the input of transaction data into a hierarchical 
system of computers. This phase is complete upon the production of a comprehensive and 
sorted Transaction Data Base (XDB). This is composed of blocks containing all transaction 
data for a given entity, and sorted by ID code, for example as discussed in detail in 
Appendix D. This data base is then processed by means of five passes, in order to 
implement delegations as appropriate, establish asset prices, execute transactions as 
appropriate, and transmit the results to custodial financial institutions. 

PrivatizelT is a general system capable of supporting a broad range of policy choices. 
It works in tandem with Privatization PlannerT, which provides a collaborative knowledge 
base in support of policy formulation. Policy choices such as the allocation of Stock 
Market Units to the citizenry will often be implemented by appropriate governmental 
transaction input to the PrivatizelT tool. Regulation such as the maximum number of 
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transactions an individual or organization is allowed to submit, and technical specification 
such as the choice of field delimiters, are used to adapt modules such as GLOPARM as 
appropriate. For more information on the customization process, refer to Appendices B and 
C. 

The Transaction Data Base (XDB) is prepared as illustrated in Fig. 5 using module 
Transact (XACT). Module XACT requests the input devices, which can include the 
terminal and auxiliary storage such as floppy disk or tape drives. The operator also 
specifies the output device and the size of any random access disk file available for sorting. 

As XACT reads transaction blocks from one or more input devices, it performs initial 
validity checks. If an error is found in the input from the terminal, the operator can 
immediately correct the transaction block, in addition to making any appropriate notation on 
the input forms. If an error is found in input from another device, the operator can enter 
additional transactions to cancel out the error and introduce a corrected substitute 
transaction. 

Module XACT performs merge-sorting into main memory on the transaction blocks 
read in. XACT notifies the operator when it stores a sorted memory buffer onto disk, and 
when it merge-sorts any disk files to the output device. If a disk is unavailable, the sorted 
memory buffer is stored directly onto the output device. XACT provides the operator an 
opportunity to change the diskette or tape after each output cycle. This allows the output to 
be subsequently merge-sorted if multiple input devices are available. 

The resulting diskettes or tapes are transmitted to the next higher node in the 
hierarchical network of processing centers either physically or electronically. For example, 
the network illustrated in Fig. 5 includes local, regional and central nodes. At the central 
computer facility, the operators generate a single comprehensive sorted XDB by iteratively 
merge-sorting the input. XDB should then be backed up and archived off-site. Throughout 
the process, the operators preserve the physical break-points in the series of tapes which 
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correspond to the logical subdivision into categories of portfolio owners such as 
governments, enterprises and citizens. 

As shown in Fig. 6, processing the Transaction Data Base (XDB) involves running a 
series of modules at the central computer facility. Detailed definitions of the files processed 
and the functions of the modules are contained in Appendix D. Module Delegatee Order 
File Generator (DORFGEN) is run on the delegatee-organization subset of the XDB to 
create the random access disk file Delegatee Order File (DORF). Upon creation, file 
DORF should be backed up, to archive and to recover from processing disruptions. 
Likewise, module Enterprise File Generator (EGEN) is run with interactive input to create 
and maintain the random access disk file Enterprise File (EPRISE), which should also be 
backed up. 

The operator then runs module PASS1 . PASS1 first requests the tapes for the 
enterprise segment of XDB to update dividend information in EPRISE, which should then 
be backed up. PASS1 then requests the entire XDB tape series, generating the serial file 
ORDERS #1 and an updated version of XDB containing reinvestment transactions. It then 
requests the tapes comprising ORDERS #1 so that module PRICING can calculate price 
estimate #1 and post it to random access files EPRISE and PRICES. The operator should 
back up EPRISE and PRICES, and then archive them, ORDERS #1 and the original XDB. 

The operator next runs module PASS2, which requests tapes comprising the updated 
XDB, and generates the serial file Delegation Offer File (DOFF) and a lending report. The 
lending report may be distributed to selected potential large borrowers, who are given a 
brief opportunity to update their borrowing transactions. Any new borrowing transactions 
are input to module XACT, along with an appropriate subset of XDB including, for 
example, only the government segment and perhaps financial institutions or even other 
enterprises. Module XACT generates a new XDB subset, and the operator archives the 
subset being replaced. The operator then runs module Delegatee Compensation 



(DELCOMP) which requests the tapes comprising DOFF, and generates the random access 
Delegates Order File (DORF). 

Module PASS3 is run next. It requests the XDB tapes and generates the serial file 
ORDERS #2. PASS3 then requests the tapes comprising ORDERS #2 so that module 
PRICING can calculate price estimate #2 and post it to random access files EPRISE and 
PRICES. These files should then be backed up and archived. 

The operator next runs module PASS4, which again requests the XDB tapes, and 
generates the final serial ORDERS file. It then requests the final ORDERS and posts the 
subsequently calculated final prices to files EPRISE and PRICES, to be backed up and 
archived. 

In the final complete pass, the operator runs module PASS5 which requests the XDB 
tapes, generates a final updated XDB file, and also generates serial file Disposition File 
(DF). The intermediate set of XDB tapes should then be archived. 

Module DISPOSE is then run, which requests the DF tapes and the financial 
institution segment of XDB. Module DISPOSE then generates a combination of reports and 
tapes or diskettes for transmittal to custodial financial institutions. A copy of these 
transmitted files and the input DF tapes should then be archived. 

The above sequence of processing steps is described from the perspective of an 
operator of the computerized market tool. Following is a description of the internal logical 
steps accomplished by that tool. Initially, a sorted and comprehensive Transaction Data 
Base (XDB) is assumed to be available. After first updating the Enterprise File (EPRISE) 
with dividend information, module PASS1 executes the first complete pass through XDB 
assuming all offers to delegate in excess of the delegatee-specified mimmums are 
consummated. At this point, the serial XDB file may be very large. PASS1 reads the 
serial XDB and the random access Delegate© Order File (DORF), which is typically much 
smaller than XDB, by calling XBLOCK, which in turn invokes modules ORDERS and 
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PRICE, to generate an initial approximation of asset prices. In the process, PASS1 
generates a new copy of XDB containing ACQUIRE transactions allocating portfolio 
earnings based on any REINVEST transaction or default. 

In a second pass, module PASS2 uses those approximate prices to value portfolio 
assets. Asset valuations are used to approximate the total amount of offers to lend to each 
entity, by maturity and interest rate. This information is made available to potential large 
borrowers to provide them with a brief opportunity to update their bids to borrow money, 
as expressed in appropriate ACQUIRE transactions. These transaction updates are input to 
XACT to update the XDB. This does not necessitate a fall pass through XDB, but only 
those tapes containing transaction data for potential large borrowers, i.e., governments, and 
perhaps financial institutions or enterprises, as discussed above. The second pass asset 
valuations are also used to create a Delegation Offer File (DOFF) of all offers to delegate. 
Module DELCOMP sorts DOFF and then calculates the two compensation thresholds for 
each delegatee by asset amount and earnings in accordance with the embedded marketplace 
for investment authority. 

Module PASS3 uses the delegatee compensation thresholds to determine which 
delegation offers are actually consummated, and generates a second approximation of asset 
prices. 

During the fourth pass, PASS4 uses the second approximation prices to determine 
whether to use a price-dependent ACQUIRE transaction or an available alternative specified 
in an immediately following ELSE transaction. Since the second pass prices were still 
approximations, the price dependencies of ACQUIRE transactions must also be understood 
as being approximate. The prices generated upon completion of this third pass are final 
prices "as or the investment cycle date. 

Module PASS5 conducts a fifth and last pass to execute transactions as appropriate, 
update portfolio valuations, and create a Disposition File (DF) containing records of assets 



to be dispensed by custodial financial institutions. 

The Disposition File (DF) is input to module DISPOSE which sorts it and outputs a 
tape/diskette and/or report of the appropriate records for transmission to each financial 
institution. Each financial institution in turn notifies the individuals or organizations entitled 
to the proceeds of consummated transactions, and makes funds available as scheduled, either 
as a principal or as an agent of the government, depending upon its category. 

It should be noted that the above description is based on an investment cycle, rather 
than continuous order matching. This is to permit the tool to be operated using minimal 
computer, communications and financial intermediary infrastructure when privatization is 
first begun, without sacrificing any significant features of a fully developed market 
resolution system. However, this tool can also be used as a real-time market system by 
reducing the period of the investment cycle from months, weeks or days to a brief interval 
defined by a sufficient number of newly-submitted transactions to ensure sufficiently well- 
behaved characteristics of the pricing behavior of a sufficient subset of the supported assets. 

The batch mode investment cycle is adapted to a real-time system in a straightforward 
manner. The generation of the sorted and comprehensive Transaction Data Base XDB using 
transported physical media and off-line terminal entry described in Fig. 5 is replaced with 
real-time transaction entry into an electronic network which channels the submitted 
transactions to a central computer. The electronic network may be implemented 
hierarchically, with each level in the network consolidating inputs into smaller numbers of 
outputs, finally producing a transaction file on the central computer. It is possible to use 
the Simulate command of the Privatization PlanneiT tool implemented on an electronic 
network with appropriate security precautions to provide an input interface into even an 
actual, rather than simulated PrivatizefT system. 

The centra] processing is then expedited for real-time responsiveness by: 1) 
sequestering modules such as AUCTION and EVOTE which have no inherent need to 



participate in a real-time market, even though they too can be more useful being 
implemented as part of a responsive electronic network; 2) deferring, as appropriate, 
relatively time-insensitive transactions such as BANK, DELEGATE, DIVIDEND, GRADE, 
JOIN, LEAVE, OVERSIGHT, PERCENTAGE, REINVEST, TRANSFER, WHEN, for 
example to off-hours processing on a daily cycle; 3) aggregating the assets under delegated 
investment authority into a composite synthetic portfolio for each delegatee-organization, 
able to be partially or completely segregated into individual portfolio-owner accounts either 
periodically or as needed; 4) relocating information storage to speed access by taking 
advantage of the smaller absolute quantities of data being processed over shorter intervals, 
for example relocating the Transaction Data Base XDB from high capacity tape to disk, and 
relocating files such as PRICES and ORDERS from disk to main memory, along with 
periodic archival of such files to higher-capacity media; 5) configuring a powerful real-time 
central computer or set of computers, and in addition optionally exploiting parallelism 
inherent in the task, such as transaction front-end preprocessing, asynchronous period- 
sampling as described below, or any element of first-approximation independence of 
separate asset prices - for example, one processor could be the initial co-recipient of all 
transactions involving government debt, along with the one or more processors designated 
as the initial recipient of one or more other assets involved in the exchange; and 6) in 
addition, the amount of processing power required to achieve convergence of price estimates 
is reduced because the initial price estimates, which are set equal to the most recent prices, 
will normally be closer to final price estimates over shorter intervals. The above-mentioned 
modules are described in detail in Appendix D. 

Successful convergence is determined by analyzing the pattern of final asset price 
estimates over a sequence of sampling periods which each start at the end of the previous 
investment cycle but successively add an additional very small interval measured either in 
time or quantity of newly-arrived transactions, as adaptively optimized, but at least equal to 
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the amount of time needed to complete the process of price estimation for the previous 
period unless parallel processors with shared information asynchronously sample cumulated 
transactions. 

The price estimate for an asset converges sufficiently when the deviation between the 
previous price and the price estimate for the first sampling period, or between the price 
estimates for a number of successive sampling periods, is within acceptable bounds based 
upon recent experience with that asset. A new investment cycle is closed when a sufficient 
number of asset prices converge. Transactions involving only assets whose price estimates 
have converged are executed, being consummated if their price conditions are met, and 
being retained for inclusion in future cycles if not - unlike the default operation in batch 
mode operation, described above. Transactions involving assets whose prices have not 
converged are retained for inclusion in future cycles. Transactions involving only assets 
whose price estimates have converged in the above sense include ACQUIRE transactions, 
even if an associated ELSE transaction refers to non-converged assets, but exclude ELSE 
transactions if an associated ACQUIRE transaction refers to non-converged assets. 

Transactions entered into the real-time system can incorporate a field containing a 
"good 'til canceled" (GTC) flag or a "good until" time which specifies the time at which the 
transaction is to be cancelled, with the default normally being cancellation at the end of a 
normal daily market cycle. It is also possible for transactions entered into the real-time 
system to incorporate a "stop price" which triggers the transaction to be executed "at the 
market" at any available price. However, the expected best method of implementation, at 
least in markets without sufficient liquidity, is to not allow "stop" orders or "market" 
orders, but rather to require each price order to have a "limit price" which must be at least 
satisfied before the transaction is consummated. Note that like in real-time mode, batch 
mode regulations may constrain the usage of "market orders" or constrain prices by setting 
"price limits" over time intervals beyond which transactions are not allowed to be 



consummated. 

The system promotes the liquidity needed for a successful real-time system. Owners 
of portfolios have access to an effective tool to continuously bid and offer assets as desired. 
The government or individual enterprise can continuously offer debt or indexed debt, 
adjusting the offered price, i.e., interest rate, and offered quantity as desired. The 
government and approved financial institutions can continuously offer annuities, also 
adjusting the offered price, i.e., the implicit interest rate, and offered quantity as desired. 
The government can post standing offers of blocks of shares of enterprises in which it wants 
to increase private holdings at prices it is able to continuously adjust, and can place standing 
bids for enterprise shares if it chooses to support those share prices or buy back shares at 
price levels it considers unrealistically low in a market sense or unacceptably low in a policy 
sense. Enterprises are able to market blocks of their shares to the public, to bid for blocks 
of their shares, for example in a "going private" process or as part of corporate finance 
strategy, or to engage in trading in other enterprise shares as allowed by any governing 
regulations. Enterprises may offer new shares intended to raise capital, or may offer with 
government approval shares held by the state. 

Delegatee-organizations are able to Ainction anywhere on the temporal investment 
spectrum consistent with their representations to the public in their disclosure 
documentation, including position trading, day trading and scalping. Since delegatee- 
organizations will be highly motivated to maximize either their total investment return or 
their assets under management, there are strong incentives for them to find, exploit and in 
the process reduce inefficiencies in price discovery among the various assets on the system, 
including SMUs and individual enterprise stocks. In addition, it is possible for the 
government to encourage market-makers pledged to enhance liquidity in specific assets by 
various incentives, such as favorable tax treatment of income, or delegations of possibly 
large blocks of government assets including the particular assets for which the market-maker 



has assumed some responsibility, conditioned upon their performance in achieving objectives 
such as helping stabilize price trajectories or marketing state-owned assets to private 
investors. 

Even individual portfolio owners with access to an effective electronic network will be 
able to submit real-time transactions. For example, if the French government vested parts 
of large state enterprises in the entire citizenry, individual citizens could access the 
PrivatizelT tool through a network like Minitel. 

This promotion of liquidity by the system not only improves the prospects for a 
successful real-time marketplace, but also improves the character of the marketplace in 
batch mode. In feet, the two modes are not inconsistent. The real-time mode provides a 
very broad and virtuously continuous investment opportunity set to a set of sophisticated 
market participants, even relative to modern market economies, and the batch mode 
provides periodic low cost access to the marketplace to a broad cross-section of citizens with 
a typically longer investment horizon. 

A more detailed discussion of the logic of the method embodied in the Privatization 
PlannerT aspect of the invention is now given in connection with Fig. 7. Hie 
Privatization PlannerT tool is an event-driven tool, which executes a loop as now 
described. 

The tool first enters a state of awaiting a user's command (step 701). When a 
command has been entered, and confirmed if so required by a particular embodiment, then 
the tool parses the command entered (step 703) to determine which of several alternative 
actions to next branch to (step 70S). In the C programming language, this action is 
commonly embodied in a CASE statement. Next, the action required by the parsed 
command is performed (step 707), after which control returns to the step of awaiting a 
user's command. The functions in one embodiment of the various commands and steps 
performed thereby are described in detail in Appendix C, however other embodiments 



including somewhat different command sets and internal command logic are contemplated as 
within the scope of the invention. Each of the commands implemented in the described 
embodiment is invoked by a user by entering the reference designator of the branch from 
the step of branching (step 705) to the desired command action (step 707). 

Having now described a few embodiments of the invention, it should be apparent to 
those skilled in the ait that the foregoing is merely illustrative and not limiting, having been 
presented by way of example only. Numerous modifications and other embodiments, 
including combinations of features found in the illustrated embodiments, are within the 
scope of one of ordinary skill in the art and are contemplated as falling within the scope of 
the invention as defined by the appended claims. 

What is claimed is: 
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Chapter 5. Universal Distribution: Potential Questions 

So far, other distribution schemes have been favored over universal distribu- 
tion. In Poland, only 30% of shares are allocated to the citizenry, and even 
those are through financial intermediaries, 30% is reserved for Polish or for- 
eign investors or the treasury, 20% goes to pension funds, 10% to commercial 
banks and 10% to enterprise employees. 68 The Russian privatization program 
provides preferential options to workers and management for roughly 40-50% 
of the capital of an enterprise, with an as yet undetermined portion of the 
balance distributed by vouchers. 5 * 

The conventional wisdom is that universal distribution is a "non-starter" pol- 
icy because of the need to accommodate stakeholders, the need for external 
discipline over management and the board of directors, and the difficulties 
of quickly achieving either privatization business plans or truly general indi- 
vidual ownership. It is therefore necessary to carefully consider each of these 
questions. 

6ft Rcpublic of Poland, supra note 55 at 10. 
59 See Chapter 8. 
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A. How Should Stakeholders be Accommodated? 

An enterprise by its nature involves stakeholders such as employees, pension- 
ers, banks, creditors and local governments. By definition, business systems 
evolve an accommodation between stakeholders and enterprises - otherwise 
the class would not be considered a stakeholder. In most states, business 
systems are embedded within a matrix of more or less clearly defined legal 
rights and customary practices. Such an infrastructure of law and custom 
is not yet in place in newly democratic nations. One line of reasoning then 
concludes that it is necessary to accommodate stakeholders by distributing 
to them an interest in ownership. 60 

However, blurring distinctions among stakeholders is counterproductive. The 
shareholders have ultimate control over an enterprise, and are entitled to its 
residual value. Hall stakeholders were to be accorded this status proportional 

to their financial interest and political clout, then enterprise ownership would 
become a crazy-quilt patchwork of national and local governments, banks, 

creditors such as other enterprises, institutions, investors, board members, 

^ eo D. Lipton, 3. Sachs, "Creating a Market Economy in Eastern Europe: The Case of 

Poland" p. 130, Brookings Papers on Economic Activity (Spring 1991). 



management, workers, and the general citizenry. Such an outcome would 
impose significant opportunity costs on household wealth and individual wel- 
fare. Unless the accommodated stakeholders usurp a sufficiently great wind- 
fall, this could even degrade their own welfare relative to more appropriately 
tailored financial support, by narrowing their portfolio and increasing its 
riskiness. 

The classic example of a stakeholder is the enterprise employee. One concern 
has been that workers unplacated by a sufficient ownership interest might 
sabotage an enterprise or otherwise thwart its privatization. However, once 
a decisive resolution to the allocation of ownership is reached, with a schedule 
to phase out enterprise subsidies, it is difficult to see how a worker would 
benefit by jeopardizing the source of his or her paycheck. A similar concern 
is that workers might quit to form their own company, in some form of 
"spontaneous privatization." To the extent such a process merely carries on 
the same business with the same clientele and capital equipment, it could 
be declared illegal and subject to the restitution of all subsequent profits to 
the state. However, to the extent that manpower is drained from inefficient, 
bureaucratic or monolithic organizations to new enterprises responsive to 



current market demands, that is a healthy process of "creative destruction." 

Another common argument is that distribution of enterprise shares to em- 
ployees is necessitated by their clout. 61 But workers of industrial enterprises 
can be replaced if their demands become inequitable, especially during an 
economic depression with collapsed demand and increasing unemployment. 
Also, industrial workers represent only a small fraction of the citizenry. In 
Poland, such workers are only 30% of the labor force, and represent about 
15% of the population. 62 In the former Soviet Union, the largest 44,000 
industrial enterprises employed about 35 million workers, representing only 
12% of its population. 63 In fact, worker ownership amounting to management 
control is a potential hazard which can degrade enterprise performance. 64 

The allocation of stock to workers who happen to be employed at an enter- 
prise on the date of its privatization is inadvisable, because it concentrates 
wealth randomly (see Appendix 1). However, an ongoing stock compensation 

plan for employees can be a legitimate component of compensation negotia- 

01 E.g., S. Fischer, supra note 33 at 5-6. 
63 D. Lipton, supra note 60 at 128. 

"Estimates from graph in IMF, et al M 2 "Study of the Soviet Economy" 37 (Feb. 1991). 
e4 H. Hansmann, "When Does Worker Ownership Work? ESOPs, Law Firms, Codeter- 
mination, and Economic Democracy", 99 Yale L. J. 1749, 1816 (1990). 
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tions. Unlike the effectively random initial conditions of profitability as de- 
termined by a history of central planning directives, enterprise performance 
after privatization and hard budget constraints take effect will be strongly 
correlated to employee performance. In sum, the best way to accommodate 
enterprise employees in particular, and stakeholders in general, is to design 
a process of privatization which maximizes the prospects for the success of 
the enterprises in which they hold stakes. 

B. Will the Board of Directors and Top Management 
Act in the Interest of Shareholders? 

i. Background 

Another common objection toward universal distribution to the entire cit- 
izenry is that it would dilute ownership rights so as to preclude effective 
control over the board and management of an enterprise. 65 The theory is 
that shareholders elect a board of directors accountable to them; the board 

of directors establishes broad policies and strategies, and appoints and over- 

65 E.g., O. Blanchard, supra note 34 at 40-41, 44; S. Fischer, supra note 33 at 19; 
B. Djelic, "Privatization and Corporate Governance in Eastern Europe: The Case of 
Yugoslavia", Harvard draft p. 12 (Dec. 8, 1990); R. Frydman, supra note 38 at 34. 



sees the chief executive officer (CEO) and perhaps other top management; 
the board of directors and top management have a collective fiduciary duty to 
conduct the affairs of the corporation in the best interests of the shareholders; 
top management hires officers which can speak on behalf of the enterprise; 
officers hire non-officer employees who can in turn form a supervisory hi- 
erarchy. If the results are unsatisfactory in the context of the competitive 
marketplace, then the board of directors is expected to remedy the situation 
- if necessary by replacing top management. If the board of directors fails 
to adequately serve the shareholders' interests, then the shareholders in turn 
elect different directors. 66 

However, in reality the responsiveness of a western corporation to its share- 
holders is often inadequate. A series of common corporate tactics can en- 
trench management and dilute effective shareholder control: inside directors 
(members of management also serving on the board of directors), golden 
parachutes (lucrative termination clauses in management employment con- 
tracts), proxy fights (management waging battles over shareholder votes ad- 

66 For an excellent review of the methods to discipline management and the board (e.g., 
earnings incentives, relative performance evaluation, career concerns, stock market mon- 
itoring such as takeovers, and creditor controls such as bankruptcy) see J. Tirole, supra 
note 51 at 7-9. 



versely affecting its position) and poison pills (unpalatable corporate changes 
automatically triggered by a successful takeover). 67 The disciplinary back- 
stop is the capital marketplace, but takeover premiums of typically 50% 
demonstrate the insulation enjoyed by management. 68 

ii. Control by Shareholders 

Shareholder control over top management and the board of directors in the 
context of extremely widespread shareholdings can be facilitated by several 
policy choices: the modulation of corporation law, shareholder voting using 
polling techniques and the delegation of authority. Corporation law can 
reflect widespread shareholdings in several ways. To promote representation 
on the board by minority factions, directors can be elected by cumulative 
voting without unnecessary classes. Voting quorums can be set at low levels. 
Tender offers to take enterprises private can be encouraged by reducing the 
required thresholds of shareholder approval. 

Shareholder votes can also be implemented with polling techniques. For a 
67 D. Hallberg, "Top Cats*, Reason 42-43 (May 1992). 

68 J. Goodman, G. Loveman, "Docs Privatization Serve the Public Interest?", Harvard 
Business Review p. 9 (Nov./Dec. 1991). 
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given decision, the enterprise would determine what percentage ownership 
represents the threshold between large and small shareholders. It would 
then submit the decision to each of the large shareholders, and a number of 
small shareholders selected at random. Each large shareholder vote would be 
weighted according to the number of shares voted, while each small share- 
holder vote would be weighted equally according to the total amount of small 
shareholdings divided by the number of small shareholders selected. How- 
ever, the probability of a particular small shareholder being selected would 
be an increasing function of the number of portfolio shares. Statutes and 
regulations can specify maximum thresholds and minimum polling sample 
sizes as a function of the size of the enterprise and the importance of the 
decision. 

Shareholder control can also be concentrated by delegation of authority. Del- 
egation of investment authority can provide market discipline as delegates 
organizations perform investment research resulting in the sale of shares of 
under-performing enterprises. Sales of a particular enterprise's shares would 
tend to depress the share price, reducing the value of compensation shares 
to the management or workers. Recipients of compensation stock in well- 
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performing enterprises would likewise be rewarded by share purchases in- 
creasing the stock price. Delegation of voting authority can also concentrate 
shareholder control by serving as an on-going and comprehensive "proxy" 
delegation. 68 

iii. Alignment of Interests via Compensation 

Another very powerful way to align the interests of shareholders, top man- 
agement and the board of directors is to tie executive compensation to the 
stock market valuation of the enterprise. The idea is to determine by statute 
that a CEO's annual compensation is a fixed multiple of national average 
wages, plus a fixed percentage of total outstanding shares to be issued from 
the enterprise treasury (see Appendix 2). Corresponding formulae for the 
board of directors, president and perhaps executive vice-presidents would 
be incorporated into the privatization business plan. This approach can be 
characterized as an emergency incomes policy designed to align the interests 
of the board and management with the interests of the shareholders. While 

incomes policies are generally defined to be anti-inflation devices, the sense 

"At the extreme, a distinct power to delegate voting authority could have national 
political significance. For instance. « -*-h Italian worker-cooperative is affiliated with one 
of three associations, each of which v connected with a national political party. H. Hans- 
mann, supra note 64 at 1795. 
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of curbing exploitation of inherent market power would apply here. 70 

Stock compensation would begin upon the privatization date specified in a 
business plan approved by some sort of Privatization Board. Vesting of ac- 
crued shares would occur only upon certification by the Privatization Board 
that any demonopolization goal which it had stipulated had been achieved. 
To further reduce the possibility of monopoly rent accruing to management 
or the board, the Privatization Board could confiscate a percentage of ac- 
crued compensation shares corresponding to its estimate of the proportion 
of the enterprise market valuation which arose from monopoly rent subse- 
quent to privatization. An exception would be that no confiscation would be 
allowed if demonopolization were achieved within a "safe-harbor" time in- 
terval. To encourage successful spin-offs in the process of demonopolization, 
the motivation to retain as large as possible a stock market base should be 
reduced. Therefore, a spin-off should pay a corresponding cash bonus to its 
parent's board and management team (as of the spin-off date), by issuing 
and selling on the market its own treasury stock. Statutory compensation 

stock would eventually be terminated by individual enterprises by the choice 

70 See generally, A. R. Braun (IMF), "Wage Determination and Incomes Policy in Open 
Economies" pp. 3-4 (1986). 



of a sufficient plurality of shareholders. 

To complement a statutory incomes policy for GEO annual compensation, 
the alignment of the interests of the board of directors and the rest of man- 
agement with shareholder interests via compensation can be operationally 
achieved in the privatization business plan for each enterprise. 71 Allocat- 
ing the non-CEO portion within the privatization business plan would pre- 
serve the flexibility to adapt the compensation plan based on the number 
and stature of directors and executive vice-presidents. Those executive vice- 
presidents would also be ideally placed to become CEOs of spin-off compa- 
nies, as enterprises transform from a u-form* to "m-form. w72 

Any inclination to begrudge compensation as a percentage of stock market 
valuation for even very large firms should be resisted. Enterprise size is not 
a definitive determinant of stock market valuation. For example, the stock 

market valuation of 17-year-old Microsoft, with 10,000 employees and sales of 

71 For a brief but cogent perspective on CEO compensation relative to other top execu- 
tives, see J. Lorsch, id. at 136. 

7a "U-form" refers to unitary-form, with organization-wide manufacturing, finance, mar- 
keting and sales departments. tt M-form" refers to a multi-divisional organization along 
broad product lines which would facilitate spin-offs. See generally, E. Pavlik, supra note 
142 at 45-51. But see J. Vickers, G. Yarrow, "Privatization and the Natural Monopolies' 1 
49 (1985), where it is argued that restructuring of monopolies should precede privatisation. 



$1.8 billion, is now as great as that of the world's biggest manufacturer: 84- 
year-old General Motors with 766,000 employees and sales of $124 billion. 73 
This is because the stock market more or less reflects the present discounted 
value of the expected stream of future, after-tax earnings. The boldness and 
initiative of top management, which would be strongly encouraged by unlim- 
ited upside potential, will play a vital role in determining which enterprises 
become highly valued and which ones fail. While .01% of stock as a compo- 
nent of annual compensation can strongly motivate the CEO of a very large 
enterprise, it is a very small price indeed relative to the potential return to 
shareholders. 74 

C. Can Privatization Business Plans be Generated Quickly? 
i. The Potential for Resistance 

One concern is that privatization business plans just won't happen, due to 
"323 (no. 7753) Economist 15 (Apr. 4, 1992). 

74 For example, the median annual average return from 1977 to 1987 of investors in the 
Fortune 500 largest U.S. industrial corporations was 14.1%. 117 (No. 9) Fortune D26 (Apr. 
25, 1988). Note also that more of the earnings would likely be distributed as dividends 
than in the west. For example, in 1988, the 1000 largest U.S. public companies had a 
cash flow of $1.6 trillion, but less than 10% was distributed to shareholders as dividends 
or share repurchases. J. Goodman, G. Loveman, supra note 68 at 9. 
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resistance. However, the enterprise leadership responsible for preparing the 
plan would presumably be heavily represented in the subsequent treasury 
stock compensation pool. It would therefore be highly motivated to rapidly 
achieve the privatization and demonopolization milestones - stock compen- 
sation "start" and "vesting" respectively (see Figure 1). Since the enterprise 
leadership is capable of providing incentives or disincentives to key employees 
even in the preparation phase, resistance can be minimized. 

Indeed, a healthy tendency may arise for relatively dynamic managements to 
rapidly formulate business plans including contiguous and desirable organiza- 
tional subunits before they are claimed by a potential competitor. There may 
be a corresponding "spontaneous liquidation" of undesirable and unclaimed 
interstitial organizational subunits. Therefore, dynamic management teams 
enthusiastically supportive of privatization will tend to acquire control over 
the salvageable portions of the organizational infrastructure. In the mean- 
time, maladaptive state enterprises will atrophy as subsidies are phased out 
and already-privatized enterprises refuse to imprudently extend credit. As 
a consequence, both the markets and the production factors of maladaptive 
state enterprises will become available to the private sector. 



Figure 1: Privatization How Chart 





Enterprise leadership prepares Privatization Business Plan (PBP) 
including: selective pasport update, claimed physical facilities, 
organization census, demonopolization goal, and 
stock compensation plan for board and management. 










Privatization Board Reviews PBP: 
resolves identified inter-enterprise "interferences'', 
approves, returns with comments or negotiates, 
establishes effective privatization date. 


Effective privatization date 




Start of stock compensation plan 






Enterprise restructuring and spin-offs. 










Privatization Board reviews enterprise application 
for certification of demonopolization: 
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ii. The Practicality of Privatization Business Plans 

Another concern is that it could be impractical to quickly generate privatiza- 
tion business plans. This issue can be analyzed by exploring what such plans 
should contain, and how they can be generated. The privatization business 
plan should contain a selective update of currently available information, 75 a 
list of claimed physical facilities, and a comprehensive if provisional organiza- 
tion chart including all available names. The generation of such privatization 
business plans is potentially a highly leveraged focal point for international 
assistance. Western academics, businessmen, lawyers or accountants, as- 
sisted by students or trainees in related fields, could provide guidance along 
with access to portable computers and menu-driven software for expedited 
diskette submittals. 

The privatization business plan should also attempt to identify potential "in- 
terferences", or potential boundary disputes with other enterprises. 76 The 

76 For example, in the ex-Soviet Union, the pasport was a collection of thirty-nine forms 
detailing the. productive capacity, capital stock and labor force of an enterprise. Each 
enterprise there has been required to complete an annual pa$pori since about 1980. E. 
Hewett, "Reforming the Soviet Economy: Equality versus Efficiency" p. 136 (1988). 

70 The use of patent law terminology is intentional, since the privatization business plan 
serves to stake a claim over a part of the industrial infrastructure, just as a patent 7 stakes 
a claim to intellectual property rights. 
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full disclosure of such potential interferences would help demarcate inter- 
enterprise boundaries. The enterprise making the disclosure would be re- 
warded by a stronger presumption of validity for an approved business plan. 
Otherwise, a conflicting privatization business plan filed within a certain pe- 
riod of time by a "contiguous" enterprise might possibly be awarded part of 
the first enterprise. 77 

Privatization business plans can be simplified by statutory resolution of cer- 
tain major - yet highly uncertain - potential rights and duties. Each en- 
terprise should be subjected by law to the "polluter pays 19 principle for fu- 
ture, and only future, liability. This clearly locates future environmental 
rights in the public, while maintaining societal responsibility for past en* 
vironmental damage. All liabilities and credits with other state enterprises 
should be discharged by law upon privatization. This is reasonable since such 
inter-enterprise transfers have arisen almost solely from centralized planning 
distortions. The net result is a newly private enterprise able to write its 

future on a clean slate. Such an enterprise can present a valuable investment 

77 The ambiguity of enterprise boundaries is a potentially serious complication. "(Tjhexe 
is an astonishing lack of information dispersed at the enterprise level about the connections 
with suppliers or customers." See W. Hogan, supra note 47 at 4. 



opportunity, and attract risk capital accordingly* 
D. Is Universal Distribution Practical? 

i. The Immediate Vesting of Future Interests as a Simple and Effective 
Expedient 

Universal distribution can be simplified by allocating each citizen a single 
"Stock Market Unit" (SMU), consisting of the right to one share of each 
enterprise privatized within some initial period, such as by the end of 1995. 
This would preserve fungibility and promote liquidity of SMUs. To motivate 
enterprise leaderships to privatize within that initial period, the statutory 
treasury stock compensation pool for the board and top management should 
be significantly reduced for any necessary follow-on interval. Such a follow-on 
interval, such as from the beginning of 1996 to the end of 2000, would have 
a corresponding tranche of "SMU2s". Therefore, part of the fluctuation in 
value of a SMU before its cut-off date would arise from changing expectations 
about the extent and timing of future privatization. SMUs would be a market 
index of expectations about future privatization prospects, and would help 
create a nationwide constituency for fast, massive and effective privatization. 
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This approach is more practical than either standard auctions or voucher 
schemes. A big problem with auctions is the absence of sufficient capital 
willing and able to bid realistically. Auctions can also be dominated by pools 
of capital raised by organized crime or through "spontaneous privatization' 1 , 
undermining the legitimacy of the transition to capitalism. In contrast, the 
SMUs represent a distribution of capital to the entire citizenry, not only 
obviating the problem of insufficient capital, but bolstering the legitimacy of 
transition as well. 

Nor are the problems associated with auctions completely cured by voucher 
schemes. While vouchers can also be universally distributed either gratis or 
at nominal prices, they impose a major information burden. Many of the 
citizens missed in voucher schemes are precisely those in the most need, such 
as the illiterate or homeless. 78 Vouchers also require the bidder at auction 
to value individual enterprises without a time series of reliable accounting 
data and in the context of major social upheaval. This problem is magnified 

because the information burden comes with time deadlines. Vouchers are 

"Note that even in Czechoslovakia, whose voucher campaign has been characterized as 
brilliant, 2.5 out of 11 million citizens did not participate. Foreign Broadcast Information 
Service (USR-92-103) 33 (Aug. 14, 1992). 
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wasting assets, becoming worthless after the corresponding auctions. 

In contrast, SMUs provide a relatively stable investment imposing a minimum 
information burden without deadlines. They are more stable because they 
represent an entire portfolio, rather than a single enterprise. The information 
burden is reduced to the decision whether to keep, sell or buy more SMUs 
at the current market price. Since SMUs would be a major standardized 
asset, price discovery and dissemination should be more effective than for a 
myriad of individual enterprises. Each participant in the SMU market would 
then be a beneficiary of the price discovery achieved by the market's most 
sophisticated participants. 

The absence of deadlines is fundamentally significant to the impact of SMUs. 

A legitimate and perhaps quite sophisticated strategy can be to simply hold 

them and collect the dividends. Since the original distribution is liable to 

resemble low-priced out of the money call options with extremely uncertain 

valuation and high implicit discount rates, 79 a "hold strategy" will allow re* 

cipients to reap the capital appreciation as the society stabilizes and implicit 

discount rates fall. The alternative is for that appreciation to accrue to so- 
79 See generally. R. Fry d man, supra note 38 at 19, 27. 
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phisticated risk capital, with adverse distributional effects. To constrain the 
rate at which people make investment mistakes, vesting intervals such as 20% 
a year for live years could be imposed on alienability. This could correspond 
to the expected learning curve in the society, while stabilizing the market by 
avoiding sudden oversupply. However, to accelerate portfolio adjustments, 
stock ownership concentration, and a reversal of the communist legacy of 
"learned helplessness", 80 immediate vesting may well be preferable. 

The distribution of SMUs can take the form of either script or of a bookkeep- 
ing entry of the entitlement in a computer system. A particular subclass of 
citizen such as adults could be provided the option to claim a certain percent- 
age of the entitlement in the form of script. This script would be stamped 
each year upon claiming the accrued aggregated dividends of the underlying 
portfolio of enterprise shares. Since this script would represent a store of 
value and might well become to a degree a medium of exchange, it could be 
viewed as a quasi-currency. While it would fluctuate with the stock market 

value, it might represent an inflation hedge against debasement of the official 

60 A. Smolar, "Democratization in Central-Eastern Europe and International Security", 
in "New Dimensions in International Security - Part IF, 266 IISS Adelphi Papers 25, 30 

(1992). 
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currency, enhancing the ability of the government to control inflation. 81 It 
would also facilitate price discovery for SMUs, as large numbers of individuals 
engaged in daily transactions at fluctuating market prices. 



However, the major form of distribution of SMUs can be as an entry in a 
computer system. Such a system can present to the entire citizenry a much 
wider range of investment opportunities. Such breadth of individual choice 
is valuable. 82 Citizens should be free to bid portions of their SMUs along 
with cash and mortgages at privatization auctions of small state enterprises 
such as shops. 83 Each individual should have the opportunity to exchange 
SMUs for selected foreign currencies, 84 government debt, shares or debt of 
a specific enterprise and annuities. The government can use the residual 

minority interest in enterprises kept in its social welfare account as a capital 

81 For a discussion on previous "bi-currency* regimes in Russia, including their ability 
to reduce the "emission tax" accruing to the government when it hyperinflates the money 
supply, see A. Arnold, "The Bipaper Standard and Hyper-Inflation*, Banks, Credit and 
Money in Soviet Russia, 175, 196 (199x). 

"World Bank, "The Economy of the USSR: Summary and Recommendations** p. 22 
(1990). 

M For a recent discussion of the status of the privatisation of retail shops in Russia, see 
L. Uchitelle, "Attention Moscow Shoppers: Everything's On Sale", New York Times 3 
(July 26, 1992). 

84 See generally, T. Lane, "Inflation Stabilization and Economic Transformation in 
Poland: The First Year", IMF Working Paper p. 15 (July 1991); J. Kornai, "The Post- 
socialist Transition and the State: Reflections in the Light of the Hungarian Fiscal Prob- 
lems", American Economic Association Meeting (New Orleans) Discussion Paper #1583 
p. 26 (Jan. 1992). 



base to insulate its budget from the actuarial uncertainties of such annuities, 
and to underwrite insurance for private financial institutions selling such 
annuities as principals. 

As part of the social safety net, part of each individual's entitlement to 
ownership in large state enterprises could be placed into a restricted "social 
security* account. The only allowed investments in this account could be 
SMUs, government debt or lifetime annuities. As citizens, children should be 
entitled to a share, perhaps calculated as the percentage of an adult share 
corresponding to relative average budgetary needs and therefore a function 
of age interval. 85 A child's share should remain inalienable until his or her 
majority, except for health or education needs. 86 A corresponding allotment 
for children born in the future should not be funded by enforced new share 
creation, which could debase the market. However, it would be possible to 

fund such allocations for future births by means of a wealth or income tax. 

"Boris Yeltsin has pledged that children shall have "first call" in Russia during the 
transition to a market economy. G. Gleason (rapporteur), "Immediate and Growing Needs 
for Help to a Fragile New Democracy: Health in the Russian Federation with Emphasis 
on Children and Women" 1, UNICEF/WHO (17 Mar. 1992). 

M In all cases, alienability could be required for heritabOity, so a child's share would not 
be inheritable, and perhaps upon death should pass by law into the national government's 
social welfare account. On the other hand, upon reaching majority it would serve as a 
sort of patrimony. 
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To help fund welfare programs for the homeless, indigent or incapacitated, 
the local or regional governments can be allotted SMUs corresponding to an 
estimate of the number of citizens who are missed in the registration. Any 
citizen registering after a certain grace period such as a year would obtain 
his or her entitlement out of the account of the local or regional government, 
motivating it to register everyone fast to maximize both regional welfare and 
its own funding base. Combining registration for entitlement to stock rights 
with voter registration could even provide positive economic reinforcement 
to the democratic process. 

ii. Logistics 

Appropriate initial logistical constraints can ensure practicality. Transac- 
tions by individuals executed by the government axe entered over the period 
of an investment cycle, which could initially be as long as a year. Trans- 
actions can be mailed or submitted in person, to either a local or central 
registry. As financial institutions and the societal infrastructure develop, 
telephone orders could be placed to brokerage houses which would guarantee 
authenticity, and relay the transactions to the central registry. Transactions 
are progressively combined and sorted by a hierarchy of computer centers, 
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resulting in a comprehensive transaction data base. At this point, the cen- 
tral computer facility processes the transactions, calculates market- clearing 
prices, and updates portfolios with current asset accounts. Even half a ter- 
abyte of storage, enough for a per capita storage allocation of five kilobytes 
in a population of one hundred million people, would cost under one hundred 
thousand dollars. 87 



87 A. Raedeke, "Technology Update: 8mm Helical-Scan Tape", CD-ROM Professional 
81, 83 (Mar. 1992). 
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Chapter 6. Policy Proposal: Immediate Universal Vesting of 
the Future Interest in Privatized Large State Enterprises 

A. Steps to Take 

i. Plan the Privatization 

The first step is to formulate a privatization strategy. This need not be 
a master plan attempting to inappropriately specify choices in advance of 
future uncertain events. 88 Rather, it should establish the direction of the 
privatization policy and fix property rights, while preserving the flexibility 
to deal with future uncertainty. 

The first element of privatization strategy is the choice of distribution tech- 
nique, whether auction, voucher or universal vesting. Immediate universal 
vesting of the future interest in privatized large state enterprises (i.e., SMUs) 
is the policy of choice. Universal distribution is equitable, fast and effective, 
and its achievement by automatic vesting is more practical and equitable 
than voucher schemes. The universal vesting must be apportioned between 

rights to script and computer accounts. At least some portion of the SMUs 
08 See R. de Neufville, supra note 138 at 320 
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could be available in script form, to solidify public support, facilitate price 
discovery and inhibit inflation. Once a distribution technique is determined, 
recipients must be identified. Potential recipients include citizens, workers, 
management, banks, pension funds, charitable institutions, local or regional 
governments, in addition to a portion bring retained by the national govern- 
ment. One effective policy would reserve a minority interest to the appropri- 
ate levels of government in social welfare accounts, and distribute the rest to 
the entire citizenry. This scries of choices is important to make early, since 
the establishment of property rights is a precondition to an effective market 
economy. 

After property rights are established, another series of policy choices must 
be made. If a computer system is implemented to support universal vesting 
of SMTJs in all citizens, then the eligible investment opportunities must be 
specified. Alternatives include government debt, other debt including annu- 
ities, enterprise shares and foreign currency. Then the types of transactions 
on the assets which the system will support must be specified. In particu- 
lar, the structure of any method of delegating investment authority must be 
addressed. 



Finally, timing must be addressed* Some timing issues must be determined 
at the outset, such as the cut-off privatization date for enterprises to be 
included in SMUs. Others should also be resolved right away, such as the 
period after which new registrants such as the incapacitated or homeless 
would be allocated their portion out of a local or regional governmental 
account. But some timing issues can be resolved later, such as the safe harbor 
time interval for achievement of demonopolization goals without subjecting 
previous management or worker compensation stock to partial confiscation. 

ii. Promulgate Legislation or Decree 

Upon formulation of a privatization policy, the appropriate parts must be 
promulgated into law by legislation, decree or agency regulations. For ex- 
ample, a legislature could establish that each citizen is entitled to one Stock 
Market Unit (SMU) representing one share in each large state enterprise 
privatized before the end of 1995, an additional 1/4 SMU to be held in a 
restricted "social security" account, 1/10 SMU to be available to adult citi- 
zens as script in denominations of 1/100 and 1/1000 SMU upon registration 
(but with the option to leave it on account), and one SMU2 corresponding 
to subsequent privatizations up to the end of the year 2000. As another ex- 
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ample, legislation or decree could promulgate an emergency incomes policy 
whereby each CEO of a newly privatized large state enterprise would be paid 
the equivalent of three national average wages plus enterprise treasury stock 
equal to .01% of shares outstanding. 

iii. Implement the System 

Once the initial planning is completed and legislation has been enacted to 
define the fundamental outlines of a privatization strategy, the system must 
be implemented. As the policy apparatus of a country analyzes the chang- 
ing situation and the policies of the national government evolve, additional 
legislation and decrees will be needed. To facilitate government manage- 
ment of a complex and challenging process, authority can be delegated to an 
agency such as a Privatization Board to review privatization business plans, 
promulgate regulations and oversee demonopolization. 

Besides the legal and regulatory structure, it is necessary to actually establish 
the systems to carry out the privatization strategy. These include person- 
nel systems to input and validate transactions, security systems to prevent 
embezzlement or privacy violations, and computer systems to process the 
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transactions. Lessons learned from the cycle of operation, maintenance and 
adaptation will then feed back into regulation and legislation. 

One way to structure an implementation strategy is by means of Privatiza- 
tion Planner™ and Privatize!™. (See Figure 2: Overview of Proposed 
Policy.) Privatization Planner™ provides a systematic overview of key 
policy choices in the privatization process. Privatize!™ sets out the design 
of a computer system to advance privatization and free markets. In combina- 
tion, they support the development and the implementation of a privatization 
policy such as universal vesting of SMUs. 

B. The Role of Selected Groups 

i. Government Policy Makers 

Different groups will have different roles in the proposed system. The govern- 
ment is responsible for formulating privatization policies and overseeing their 
implementation. This initially involves legislation or decrees which resolve 
property rights, establish a management incomes policy as appropriate, and 
delegate authority to an agency to oversee the privatization process. Sub- 
sequently, that agency must promulgate regulations to provide guidance to 
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Figure 2: Overview of Proposed Policy 



Research and Analysis 



Privatisation Planner™ 1 



Privatise!™ 



Privatisation Planner™ 



Privatize?™ 



Establish property rights 



j Formulate incomes policy 



j Structure privatisation sequence 




Privatization Business PUn* 




Effective Privatisation Date 1 




Demonopolisation Date 






Establish oversight agency 



Customize Privatise!™] 



Select assets to support 



Select transactions to support 



Choose parameter values 

~l 



Portfolio owners and delegatees submit transactional 



i 



Processing centers generate Transaction Data Basel 



I 



Central computer processing | 



Generate reinvestment transactions] 
Establish valid delegations j 



Select between alternative transactions 



Calculate clearing prices | 



Transmit results to financial institutions! 



Support enterprise shareholder votes 



Support aucti on of small state enterprises 

i 



54 



and constraints upon the process. For example, professional organizations 
which accept investment authority over part of a portfolio in return for a 
share in the profits or assets could have a limit on the rates they charge. The 
agency itself must in turn be overseen by the legislature, executive and/or 
courts, -who are in turn responsible to the citizenry in whom the entitlement 
to SMUs was created. 

ii. Enterprise Management 

Enterprise management must first develop a privatization business plan. This 
will often involve a search for identity, as leadership concentrations in an 
interwoven industrial infrastructure determine where their organization ends 
and their suppliers and customers begin. A key step in this phase is the 
emergence of a CEO, board of directors and top management, along with 
their stock compensation agreements. This process should involve interaction 
with the Privatization Board, so that the resulting privatization business plan 
is likely to be the product of negotiated decisionmaking, rather than the start 
of regulatory confrontation. In the case of heavily concentrated industries, 
executive vice-presidents should be placed in positions to coalesce any spin- 
offs needed to achieve demonopolization goals required by the Privatization 
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Board. 

The Privatization Board may be authorized or directed to consider wage 
compacts as part of the Privatization Business Plan, in order to cushion 
the shock of transition on workers. This is inadvisable if workers have al- 
ready received SMU entitlements including "social security" accounts, since 
it would constrain management from maximizing the value of the enterprise 
to its shareholders - the entire citizenry. However, management and workers 
should both seriously consider including stock compensation as part of wage 
negotiations. 

Upon privatization, enterprise management can begin to accrue compensa- 
tion stock. Vesting of such stock should be deferred until the Privatization 
Board has certified demonopolization. If demonopolization occurs after a 
safe harbor time interval, the Privatization Board should confiscate the part 
of management and worker compensation stock which it estimates to be at- 
tributable to monopoly rent arising subsequent to privatization. Spin-offs 
which survive an initial interval should liquidate a number of treasury shares 
determined by Privatization Board regulations and pay the proceeds to its 
parent organization's management as constituted at the date of spin-off. 
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Enterprise managements can also ensure that their organizations serve as 
data entry foci into the computer system. Enterprises would generate trans- 
action data for their own portfolio, and records of employees along with 
negotiated stock compensation amounts. In addition, enterprises can serve 
as data entry centers for transactions by their employees, and perhaps on a 
compensated basis even for other members of their local community. 

iii. Portfolio Owners 

The proposed system places all citizens into the role of portfolio owners. As 
such, they axe capable of evaluating alternative investments and entering 
transactions at local registries or enterprises. 

While part of each owner's portfolio would remain on account with the gov- 
ernment (for instance, at least the "social security" account), the remainder 
could be transferred to the individual's choice of financial institution for 
safekeeping and access. 

iv. Processing Centers 

From the perspective of processing centers, each is a node in a hierarchical 
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network of information flow. Each center receives transaction data from dif- 
ferent sources, sorts and combines it, and passes it to the next higher node. 
The lowest nodes may receive virtually all transaction data from forms re- 
quiring data entry. Progressively higher nodes such as regional centers would 
typically handle as input the diskettes or tapes generated by the lowest nodes, 
and then send a single set of tapes on to the the next higher node. Eventu- 
ally, a single composite data base is produced at a central processing facility. 
This data base is then processed to execute transactions as appropriate, and 
the results transmitted to custodial financial institutions. 
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Chapter 7: Expected Effects of the Proposed Policy 
A. Things Going Wrong 
i. Confusion 

Confusion inevitably accompanies great social change. In particular, the 
transition from centrally planned economies to free markets involves the de- 
programming of decades of indoctrination. Basic concepts are alien. The 
"invisible hand" of Adam Smith seems a fairy tale. Profits all seem illicit. 
Private property seems anti-social. Initiative seems dangerous, while the dan- 
ger of joblessness and poverty is frightening. The result can be bewilderment, 
and inconsistent or even directionless policy. 

The implementation of the proposal for universal vesting of the future interest 
in privatized large state enterprises will be associated with more confusion. 
The concept of vesting an intangible future interest may seem novel. The 
different participants in the system - government policy makers, enterprise 
management, portfolio owners and processing centers - may not at first fully 
understand their respective duties and options. 



The antidotes to confusion axe dear policy directives, education and training, 
and patience. Each of these antidotes can be available. The universal vesting 
of the future interest in privatized large state enterprises may be novel, but 
it can be sold with clarity to a public in search of a system with legitimacy 
and better living standards. Education and training have international and 
domestic aspects. Exchange programs where citizens of newly democratic 
nations travel abroad to learn while members of successful democracies take 
their place to teach are already growing in scope. On the domestic side, while 
there is typically a dearth of teachers qualified to teach advanced courses in 
western business practices, the educational infrastructure is in many cases 
a strong asset capable of redirection. Finally, a certain interval of time is 
needed to successfully navigate such an expanse of social change, so patience 
is essential. 

ii. Delays 

The proposed policy involves the development of personnel systems, security 
systems and computer systems. All can be associated with notorious delays. 
Delays erode credibility, and credibility is the coin of government. 



Two factors mitigate this problem. First, actual property rights can be cre- 
ated immediately upon the promulgation of universal vesting. These property 
rights are real, and could immediately be used to bid at auctions of small 
state enterprises. Script for a small portion of the new property rights could 
be issued right away to tangibly demonstrate the transfer of wealth from the 
government as custodian to the individual citizens as owners. If there is a 
delay in operationalizing the personnel, security and computer systems, the 
new asset will not be impaired - alternative investment choices will only be 
deferred. If the initial delay coincides with a process of stabilization, then 
exorbitant discount rates could be punctured and share values could increase, 
to the benefit of the citizenry. At any rate, the challenge in such an endeavour 
and its potential advantages would be no secret, and given the opportunity, 
a society collectively can have great sophistication in its evaluation of the 
performance of a government. 

The other answer to delays is priority. One weakness of centrally planned 
economies has always been the inability to handle well the myriad simul- 
taneous decisions facing a modern society. On the other hand, they often 
have demonstrated the capacity to do "any thing." That is, given enough 
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priority, a particular objective could be achieved in world-class fashion. If 
the transition to democracy goes hand in hand with free markets, and if free 
markets are contingent upon privatizing large state enterprises, it would seem 
appropriate for policy makers to allocate the human and material resources 
to achieve that goal as rapidly as possible. 

iii. Transaction Processing Errors 

It can be assumed that every possible error will happen. Fictitious citi- 
zens will be registered. Homeless, incapacitated and illiterate citizens will be 
missed. Actual portfolio owners will request transactions they don't mean. 
Data entry personnel will input transactions other than directed. Intermedi- 
ate processing centers will lose segments of the transaction data base. The 
central computer facility will encounter software and hardware glitches, and 
oerator errors. Choice of delegatee-organizations, choice between alternative 
orders, and matching buy and sell orders will occur at approximate prices. 
Assets intended to be transmitted to custodial financial institutions will be 
delayed or lost. At each stage of the process, individuals outside government 
without authorized access and individuals within government with autho- 
rized access will attempt to use information improperly. While each of these 



62 



problems occurs in mature market economies as well, it can be expected that 
their magnitude will be greater in newly democratic nations. 

Problems will occur with any privatization policy, and the proposed policy 
can effectively address problems which do arise. Standard audit practices can 
raise the cost of fictitious registration: requiring local authentication at ini- 
tial registration, random checking of the legitimacy of registrants, analysis of 
data for suspicious patterns, penalties assessed against the social welfare al- 
location of local governments with poor records in allowing fictitious entries, 
and restitution of falsely claimed assets with additional penalties correspond- 
ing to the number of false registrations likely to be missed. Allocating late 
registrants (e.g., a homeless person registering after two years) their entitle- 
ment out of the local government's social welfare portfolio will encourage it 
to initially miss as few as possible. 

To minimize portfolio owners entering transactions they don't mean, infor- 
mation can be distributed to clarify choices. Still, some mistakes are part 
of the tuition in traversing the learning curve. If data entry personnel enter 
erroneous records, they can be canceled. If segments of the transaction data 
base are missing, the regional centers can attempt to validate completeness 
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and request missing segments. When errors are caught, any consequential 
loss sustained by the portfolio owner can be made good out of the responsible 
government's account, which would likewise accrue any consequential gain. 

At the central computer facility, processing disruptions may necessitate re- 
covery procedures such as reprocessing from the latest backup. Software 
glitches may be identified and patched. The degree of price approximations 
will be a function of processing power available, more a function of west- 
ern export licenses than technological constraints. Transmittals to custodial 
financial institutions will be backed up and available for retransmittal as nec- 
essary. Improper use of the information data bases can be dealt with by law, 
so that what could have been Orwellian technology can instead be harnessed 
in the interest of economic security and individual liberty* 

B. Things Going Right 

i. Immediate Resolution of Ownership Rights 

A fundamental advantage of the policy to universally vest future privatization 
interests is the immediate resolution of ownership rights. While the wealth 
transfer is intangible until distributed as script, used in a bid at auction, or 
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accessible with a computer system, it is real nonetheless. It can boost current 
household wealth and future household income, providing a non-inflationary 
stimulus to the economy. 

The proposed policy is superior to alternatives which include as recipients 
entities other than governments or citizens (e.g., enterprise employees). The 
reason is that to a first order approximation, with universal vesting the estab- 
lishment of inter-enterprise boundaries does not affect wealth distribution. 
Indeed, it becomes in the interest of the citizenry and the hierarchy of gov- 
ernments to approve enterprise boundaries which maximize their aggregate 
rather than individual worth. 

ii. Individual Social Security: "Safety Net" 

Universal vesting also provides an important safety net to individual citizens. 
The "social security" segment of an individual's portfolio can be restricted 
to portfolio stock, government debt or lifetime annuities. This social security 
account is a meaningful asset which can be disbursed for medical or living 
necessities. The allocations to children can provide needed support, finance 
education and help prevent intergenerational poverty cycles. In the process 
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of providing an individual safety net, the social security account will also 
reduce the social welfare burden on future government budgets. 

iii. Individual Economic Opportunity: "Trampoline" 

The unrestricted portion of a citizen's portfolio is a valuable patrimony. It 
can be used to bid at auctions of small state enterprises, start a business, 
relocate a family, buy land or make alternative investments. While some 
individuals may be shrewder or luckier, all can receive the same economic 
opportunity. The result can unleash the economic power of decentralized 
decisions conforming to each individual's personal utility. 

iv. Promotion of a Free Market 

Universal vesting of future privatization rights can promote free markets. It 
can be instrumental in the rapid and effective privatization of large state en- 
terprises, which is essential for valid price signals. It can create opportunities 
for alternative investments such as foreign currencies. It can also promote 
capital formation by accelerating the creation of markets in individual enter- 
prises, accessible to citizens and foreign investors alike. 



v. Transition to Private Financial Institutions 



The proposed system incorporates the concept of promoting the transition to 
private financial institutions- Individuals can transfer assets (except perhaps 
from the "social security" account) into approved custodial financial institu- 
tions of their choice, gaining more privacy, faster access and the ability to 
change investment strategies more rapidly. This can also provide a source of 
capital to new financial institutions, which can then serve as capital inter- 
mediaries to enterprises in growth industries* 
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Appendix 2: Sample Screens 

The following screens are samples illustrating typical screen layouts and page 
contents. 

In order to double up screen output onto a laser printer, two additional com- 
mands have been implemented: 

L draws a solid line across the middle of the page after the first screen has been 
printed; 

F issues a form feed to eject the page after the second screen has been printed 
beneath the first. 



WO 94/10637 
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FlT/USSM/lUM/ 



rivatization Planner (tm) 

Privatization Planner (tm) 

" You are wjh, looking at the default version, with default values- 

his software package is designed to support the systematic 
ormulation of privatization policy. An initial data base of 
nformation will provide a basic tutorial on the issues and 
ptions in privatizing large state enterprises. 

ach "generation" a primary version and selected alternates 
ill be distributed. Users can then evaluate and comment on 
he various screens and pages , and submit proposals for added, 
eplaced or deleted screens and pages. 

•ased on the aggregated evaluations, inferior alternatives 
ill be pruned before the next generation. Authors of retained 
nformation can be given the opportunity to edit their material 
ased on the evaluations and comments received. 



nter command: 

Page Add Replace Delete Values Eval Screen User Help Quit 
0-2 1-2 1-2 1-2 mode [id] 



'rivatization Planner (tm) Fri D ct 16 00:47:12 1992 

Privatization Planner (tm) 

*~~---Xou are w ^ h ' lookin 9 at the default version, with default values 

Next Higher Screen (SO for Root) 

1 Introduction 

2 Methods of Share Distribution 

3 Timing Considerations 

4 Privatize! (tm) Customization 

5 Administrative Information 



nter command: 



creen Add Replace Delete Title Eval Page User Help Quit 
°" 5 1-5 1-5 1-5 mode [id] 
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?rivatization Planner (tm) 

Privatize! (tm) Customization 

You are wjh, looking at the default version, with default values- 

3 Next Higher Screen (SO for Root) 

31 Files 

32 Modules 

33 Transactions 

34 Assets 

35 Financing the system 



Snter command: 

Screen Add Replace Delete Title Eval Page User Help Quit 
0-5 1-5 1-5 1-5 mode [id] 



Privatization Planner (tm) Fri Oct 16 00:48:39 1992 

Financing the system 

You are wjh, looking at the default version, with default values 

3 Next Higher Screen (SO for Root) 

31 General budgetary resources 

12 Enhanced tax collection over portfolio earnings 

33 Tax on portfolio assets 

34 Fee based on size of transaction block 

35 Fee based on number of transactions 

36 Fee to support enterprise votes 

37 Fee to register enterprise debt instruments 

38 Implicit Arbitrage Revenue 



:nter command: 



Jcreen Add Replace Delete Title Eval Page User Help Quit 
0-8 1-8 1-8 1-8 mode [id] 
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rivatization Planner (tm) 

Files 

You are wjh, looking at the default version, with default values- 
Next Higher Screen (SO for Root) 

1 Disposition File (DF) 

2 Disposition File - Excerpts (DFXXXX) 

3 Delegation Offer File (DOFF) 

4 Delegatee Order File (DORF) 

5 Enterprise File (EPRISE) 

6 Order File (ORDERS) 

7 Asset Price File (PRICES) 

8 Transaction Data Base (XDB) 



nter command: 



creen Add Replace Delete Title Eval Page User Help Quit 
0-8 1-8 1-8 1-8 mode [id] 



•rivatization Planner (tm) Fri Oct 16 00:51:05 1992 

Modules 

You are wjh, looking at the default version, with default values 

Next Higher Screen (SO for Root) 

1 ACTUARY (calculates periodic annuity payments) 

2 AUCTION (supports bidding with SMUs at small enterprise auctions) 
;3 DELCOMP (calculates threshold delegatee compensation) 

:4 DISPOSE (prepares transmittals to custodial financial institutions) 
;5 DORFGEN (generates Delegatee Order File - DORF) 
:6 EGEN (generates Enterprise File - EPRISE) 
•7 EVOTE (supports polled shareholder voting) 

8 PASS1 (transaction processing: first pass) 

9 PASS 2 (transaction processing: second pass) 

10 PASS 3 (transaction processing: third pass) 

11 PASS 4 (transact ion. processing: fourth pass) 

12 PASS 5 (transaction processing: fifth pass) 

13 PRICING (determines market-clearing prices) 

14 XACT (generates the Transaction Data Base - XDB) 

15 XBLOCK (analyses a transaction block) 
inter command: 

creen Add Replace Delete Title Eval Page User Help Quit 
0-15 1-15 1-15 1-15 mode [id] 
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•rivatization Planner (tm) 

Transactions 

You are wjh, looking at the default version, with default values 

Next Higher Screen (SO for Root) . , . 

1 ACQUIRE (attempt to obtain an asset in exchange for another) 

2 BANK (financial institution to process debt payments of an enterprise) 

3 CANCEL (cancel previous, unexecuted transactions) 

4 DELEGATE (delegate investment or voting authority over specified assets 

5 DIVIDEND (total dividends paid by an enterprise to shares on the system) 

6 ELSE (alternative ACQUIRE transaction if first price contingencies not met) 

7 FILTER (delegatee orders to apply to selected portfolios or assets) 

8 GRADE (evaluation of financial institution) 

9 IDENT (identification of portfolio owner) 

10 JOIN (enterprise employee stock compensation and date of hire) 

11 LEAVE (date enterprise employee ceases employment) , . _ 

12 OVERSIGHT (dates of privatization and demonopolization; confiscation %) 

13 PERCENTAGE (minimum compensation acceptable to delegatee organization) 

14 REINVEST (specifies how portfolio earnings are to be invested) 

15 SECURITY (apply transactions to "social security" portion of portfolio) 
;16 TRANSFER (transfer specified assets to particular financial institution) 
Inter command: 

;creen Add Replace Delete Title Eval Page User Help Quit 
0-16 1-16 1-16 1-16 node [id] 



»rivatization Planner (tm) Fri Oct 16 00:52:25 1992 

Assets 

You are wjh, looking at the default version, with default values 

; Next Higher Screen (SO for Root) 

;i ALL (composite of all assets in portfolio) 

'.2 DXXXX (debt of specific borrower, as an asset in lender's portfolio) 

53 DIXXXX (debt indexed for inflation) 

;4 EXXXX (stock in specific enterprise) 

55 FCXX (foreign currency) 

•6 PAYOUT (generalized annuity) 

57 SMU (Stock Market Unit, basket of shares privatized by 199x) 

:8 SMU2 (2d trance of SMUs, basket of shares privatized between 19 9x and 200y) 

;9 VOUCHER (privatization voucher) 

;10 Virtual Asset - DR (donation "right" transferred to donor for gift) , 
;il Virtual Asset - LSER (large state enterprise rights exchanged for SMUs) 
;12 Virtual Asset - SSER (small state enterprise rights) 
;13 Virtual Asset - TR (testamentary rights) 

.14 Virtual Asset - VAL (value received external to the software system) 
:nter command: 

screen Add Replace Delete Title Eval Page User Help Quit 
0-14 1-14 1-14 1-14 mode [id] 



Appendix 3: Program Listing 



The following listing sets out the source code for Privatisation Planner™, 
which has been implemented up to the stage where the system coordinator 
evaluates and selects information for redistribution. 
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/* Privatization Planner (tm) Version 0.7 */ 

/* Processing directives, function declarations 9 
global variable declarations */ 

/* October 15, 1992 (copyright 1092 by William J. Bartnett) */ 

#include <stdlib.h> 
tinclude <dir.h> 
#include <stdio.h> 
♦include <string.h> 
♦include <conio.h> 
#include <dos.h> 
♦include <io.h> 
#include <fcntl.h> 
#include <sys\stat .h> 
♦include <tine.h> 
♦include <process.h> 
#include <tcntl.h> 

/* largest # of inserted files per user per level */ 

«define MAXIFILE 100 

#def ine USERSLH 2000 

#def ine UDELIH M * M 

♦define YMAX 30 

♦define PAGELEN 1600 

♦define MAXSP 300 
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#include<\te\tpp\includs .c> 
void adopt (int k); 

void loginO, paintp() 9 paints() 9 rtrnO; 

void screen() 9 survey() 9 updtfQ, varval(int i 9 char val[80]); 

int addrep(char fna[MAXPATH] , int place); 

void xcerpt(int iswitch); 

int idcheckO; 

char* fn(char filename [9]); 

char* fn2(char filename [9] ) ; 

void uemnd(char whence [7] ) f vcmndO; 

FILE +maps» *mapp 9 *react, *title; 

•tract ffblk ffblk; 

int output 9 updtB, updtp 9 updtr, status; 

int wtl f wt2 f wt3 9 wt4; /* title window corners */ 

int wxl,wx2 f wx3,wx4; /* screen/page window corners */ 

int wil,wi2,wi3 f wi4; /* interaction window corners */ 

int wfl 9 wf2 9 wf3 9 wf4; /* footer window corners */ 

int uhandle; 

int ips 9 pa, nsptot[2], nspid[2] ; 

int spfirst[2] 9 splast[2] 9 spfcode[2]; 

int newpage, usepage; 

int xval[30],yval[30],lval[30],nval; 

char sparray[7800] 9 response [240] 9 pagedataCPAGELEN] ; 

char sp[2][MAISP] [13] , sptext[2] [10], spchar[2] [2] ; 

char t[80] 9 tnok[80] , r [2000] , idch[13] ; 

char drive [MAXDMVE] 9 pf ile [M AXPATH] ; 

char pathCMAXDIR] , cwd[HAXDIR] ; 

char f name [MAXPATH] ; 

char dum[160] ; 

char userid[6] 9 varid[6] t usersinfo[USERSLH] ; 
char *ptr , whence [7] ; 
char timbuf [27]; 
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♦include <\tc\tpp\global.c> 
/* Program Main — The root module. */ 

mainO 

< 

char reaction [1000] , cfirst; 

char Inm [MAXPATH] , curdir [MAXPATH] , orgdir [MAXPATH] ; 
char newidch[5] ; 
char *cwdext; 

Int handle » idexist, dummy, newdir, place; 
int 1, j; 

wtl«l; wt2=3; wt3*80; wt4«l; /* title window */ 
wxi=l; wx2«5; wx3=80; wx4*21; /* screen/page window */ 
wil=l; wi2=22; wi3=80; wi4=23; /* Interaction window */ 
wfl«l; wf2=24; wf3=80; w*4=25; /* looter window */ 

getcwd(orgdir v NAXPATH) ; 

strcpy(tnok, "title missing 91 ) ; 
printf ("tnok: %s\n",tnok); 
atrcpy(sptext [0] /'screen") ; 
strcpy(sptext[l] /'page") ; 
strcpy(idch t ""); 
strcpy(varid,""); 
strcpy (sparray , HULL) ; 

•trcpyUspchartO] [0],"S"); atrcpy(Aspchar[l] [0] ,«P»); 
splcode[0]=FAJ>IREC; spf code[l]«0; 

clrscrO; 

printf ( "Privatization Planner (tm) Terson 0,7 \n\n"); 
printf ("Copyright 1992 by William J. Bartnett \n»»); 
printf ("enter debugging level [0«none, 9&lots]: ••); 
scanf ("Xld" 9 ftoutput) ; 

printf ("\nEnter disk drive lor plan lile [e.g., 'a:']: •'); 
scanf("Xe", drive); 

il (output >= 9) printf ("drive* %s\n", drive); 

printf ("\nEntcr directory of plan lile [e.g., 'planner*]: «) 

scanf(" f /.s»,pfile); 

pfile[8]=»\0'; /* truncate name at 8 bytes, if longer */ 
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if (output >= 5) printf( M drive= Jis, filers \n", drive .pfile); 
■trcpy (path , drive ) ; 
atrncat (path/'W ,2) ; 
strncat (path, pfile, 9) ; 

if (output >= 3) printf ( M path= %s\n" .path) ; 
skdir(path) ; 
chdir(path) ; 

loginO; 

newpage=l ; usepagesl; 

strcpy(r,"\0"); 
street (r,UDELIM); 
street (r,userid) ; 
strcat(r,"\n"); 

survey (); 
ps=i; 

•tart: if(ps==l) paintpO; 
else paints (); 

/+ input command and process */ 

prompt: vindov(vil,vi2,*i3,vi4) ; clrscrO; 

print f ("Enter command: "); 

cmnd: acanf ("Xs" f response) ; 

cf irst=toupper (response [0] ) ; 

gotoxy(l,2); 

if (output >= 9) 

print f ("command string: %s , cf irst : %lc\n" ,respense ,ef irst) ; 

switch (cfirst) { 

/* printer support functions +/ 
case 'L»: /+ bisect page +/ 

strcpy (response f " \n\n\n\n 

f write (response ,1,88, stdprn) ; 
break; 

case »F»: /* eject page */ 

fwriteC' f, t i,i f stdprn); 

break; 
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/* 

The S command supports changing to another screen 
(or switching into screen mode from page mode) • 
♦/ 

case 'S 1 : 



if(ps«l) 

{ 

npdtfO; 

¥indow(l,l f 80,26); 

clrscrO ; 

ps«0; 

goto start; 
> 



if (ps~0) 
{ 

nevdirsatoi(toesponse[l] ) ; 

if ( (nevdir<0) 1 1 (ne«dir>n8pidCps] ) ) 

{ 

gotoxy(l,l); 

print! ("Must be in form S (to go up) or S'/.d to S'/,d.\nTry again: " f O f nspid[ps] ) 

goto cmnd; 

> 

updtf(); 

if(newdir>0) 
{ 

strcpy(f nm,drive) ; 

street (f nm,*sp[ps] [spf irst [ps]+nevdir-l] [0] ) ; 
> 

else 

{ 

if (stxncmp(*response[l],"0'',l) == 0) 
{strcpy(fnm,path); goto doit;} 
else 



getcvd(curdir,MAXPATH) ; 
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if (strcmpi(path,curdir) == 0) 
{ 

gotoxy(l,l); clrscrO; 

printf("Ho higher directory available. V); 
print f ("Try a different command: "); 
goto cmnd; 
} 

else 

strcpy(fnm»". .") » /* eO — > next higher directory 
> 

} 

doit: chdir(fxun) ; 
survey (); 
goto start; 
} 

print 1 ("Big trouble: ps isn't 0 or 1!"); 
exit(statU8); 
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/♦ »/ 

case 'A 1 : 

if (idcheckO < 0) goto emnd; /* change disallowed */ 

place=atoi(ftresponse[l]); /* where to place */ 

if (place == 0) place = nspid[ps]+l; 

if ((place < 1) II (place > nspid[ps]+l)) 

{printf ( "Must be in form A (append new screen) , or AXd to A%d.\n"» 
I,nspid[ps]+i); 
printf("Try again: ••); 
goto cmnd;} 

if (addrep(fnm,place) < 0) goto cmnd; 

if(nsptot[ps] >= MAXSP) 

i 

print* ("Total number of screens equals */.d ~ all full!" 

Try something else: " 9 nsptot [ps] ) ; 
goto cmnd; 
> 

xcerpt(l); 

if (splast[ps] < spfirst[ps]) /* first sequence for this id ♦/ 

if (place !e 1) 
{ 

printf ("New sequence, but place != 1???"); 

rtrnO; 

> 

»trcpy(*sp[ps] fesptot [ps]] [0] , W U") ; 
street (Asp [ps] [nsptot [ps]] [0] ,idch) ; 
strcpy(Asp[ps] Dasptot [ps]+l] [0] ,fnm) ; 
nsptot [ps] «nsptot [ps] +2 ; 
> 

else /* update sequence for this id*/ 

{ 

for(i=nsptot[ps] ; i>»spf irst[ps]+place-l; i~) 
strcpy (Asp[ps] [i+1] [0] ,*sp[ps] [i] [0] ) ; 
strcpy(Asp[ps] [spf irst[ps]+place-l] [0] f fnm) ; 
nsptot [ps] snsptot [ps] +1 ; 
> 

break; 
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/♦ ♦/ 

case >R': 

if (idcheckO < 0) goto cond; /* change disallowed */ 

placesatoi(ftresponse [1] ) ; 

if ((place < 1) II (place > nspidCps])) 

<gotoxy(l,l) ; 

if (nspid[ps] >= 1) 

printf ("Must be in form R7.d to R%d. Try again: ",l,nspid[ps]); 
else 

printf ("No %ss to replace. Try again: " »sptext [ps] ) ; 
goto cmnd;} 

if (addrep(fnm f place) < 0) goto cmnd; 
xcerpt(l) ; 

if (splast[ps] < spfirstCps]) 

{ 

printf ("Logic error in »R» command."); 

exit (status); 

> 

strcpyUspCps] [spfirstCps] +place-l] [0] t fna) ; 
break; 



/. ./ 

case 'D f : 

if (idcheckQ < 0) goto cmnd; /* change disallowed */ 

placesatoi(*response [1] ) ; 

if ((place < 1) || (place > nspid[ps])) 

{gotoxy(l,l) ; 

if(nspid[ps] >= 1) 

printf ("Must be in form D'/.d to D%d. Try again: '\l,nspid[ps]) ; 
else 

printf ( "No %ss to delete . Try again : " , sptezt [ps] ) ; 
goto cmnd;} 

xcerpt(l); 

if ( spies t[pe3 < spfirst[ps3) 

{ 

printf ("Logic error in 'D' command."); 

exit (status); 

> 

for(i = spfirst[ps]+place-l; i <* nsptot[ps]-l; i++) 
strcpy UspCps] [i] [0] ,*sp[ps] [i+i] [0] ) ; 
nsptot [ps] ansptot [ps] -1 ; 

if (ps— 0) npdtssl; 
else updtp=l ; 
break; 



82 



/. ,/ 

case 'T>: 

if (ps«l) goto nogood; /* only works vith screen mode */ 
getcwd(cwd,MAXDIR); 

cvdexts8trrchr(cvd,atoi('.'))+l; /* e.g., (.)abc */ 
if (strlen(cvdext) > 3) strcpy(cvdext,""); 
if (strcnpi(u8erid,cvdext) Is 0) 

< 

gotoxy(l,l); clxscrO; 

prizitf ("Can't change title of adopted screen! Try something else: "); 

goto cmnd; 

} 

if(idcheck() < 0) goto cmnd; 
gotoxy(l,l); clrscrQ; 

printf( "Enter new title for this screen:\n") ; 

rewind (stdin) ; 

scanf( N %C-\n]« 9 t); 

8trcpy(fnm,drive) ; 

strcat(fnm, "title"); 

b treat (fnm ,"."); 

s treat (fnn,idch); 

handl«=open(fnm, 0 JU)WR 1 0_ CHEAT ,S_IREAD I S.IWRITE) ; 
if ( (output >=6)**<handl«<0) ) 

< 

perror("plan.c M ); 

rtrnO; 

> 

write (handle » t , strlen ( t ) +1 ) ; 

close(handle); 

if (output >= 9) 

{ 

gotoxy(l,l); 

printf ("screen fnm: %b 9 handle^ %5d\n",fni&, handle); 



break; 



83 > 



/* */ 

case *E 9 : 

if (strcmpi(idch,userid) == 0) 

{print f ("Cannot evaluate own setup! Try a different command: ") 
goto cmnd;} 

g«tcyd(path,MAIPiTH) ; 

f nspli t (path v dun , dum , f nm , dum) ; 

print f ("Please evaluate this %s (l=very poor, 6=very good): 

*sptext[ps] [0]); 

revind(stdin); 

•canf( l 7.s ,, > dum); 

if (strlen(dum) >= 1) 

{ 

if (p B « 0) street (r ,"."); /* "." denotes current screen */ 

else street (r ,tsp[ps] [usepage] [0] ) ; 

s treat (r," £ "); 

street (r,dnm) ; 

strcat(r f "\n"); 

updtr«l; 

> 

clrserO; 

print f ("Please enter any comment on this %s:\n",ftsptext[ps] [0]) ; 
revind(stdin) ; 
acanf("X[-\n] ,, f dum); 
if (strlen(dum) >= 1) 

i 

if(ps == 0) street (r t f \ M ); 

else street (r ,*sp [ps] [usepage] [0] ) ; 

street (r f " C "); 

street (r,dum); 

street (r,"\n M ); 

updtrsl ; 

> 



break; 
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/* ♦/ 

case >P>: 
if(ps==0) 

{ 

updtfO; 

window(l f i,80,25); 

clxecrO; 

P«=i; 

goto start; 
> 

if(ps*=l) 

{ 

newpagesatoi(fcresponae[l] ) ; 

if(nevpage " 0) nevpage = usepage + 1; 

if ( (nevpage<0) 1 1 (nevpage>nspid [ps] ) ) 

i 

gotoxy(l 9 l); 

printf ("Must be in torn P (increment unless last) or P*/.d to PV.d. Try again: 

0 t nspid[ps]); 

goto cmd; 

> 

nsepagesnevpage ; 
goto start; 
> 

printXC'Big trouble: ps isn't 0 or 1!"); 
exit (status) ; 
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/* */ 

case 9 U J : 
ucmnd( whence) ; 
survey (); 

if (strcmp( whence /'prompt ")==()) goto prompt; 

if (strcmp( whence f M csmd M )==0) goto cmnd; 

if (8trcmp(vhence,"8tart") ss 0) goto start; 

print! ("OCMHD done. What now?? Whence = '/.fl" , whence) ; 

exit (status) ; 

case 

if (ps == 0) goto nogood; 
vcnndO ; 
goto start; 



case 'H 1 : 

/* add on-line help +/ 

if (output >= 9) print f ("switch case H") ; 

break; 

case 'Q f : 
updtf(); 

window (1,1 ,80,25); 
clrscrO; 
chdir(orgdir) ; 
exit (status) ; 

default : 
nogood : got oxy (1,1); 
print f ("Invalid command. Please enter new command (H for help): H ) 
goto cmnd;} 

goto start; /* cycle up for another command */ 



> 
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/* Privatization Planner (tin) Subroutines */ 



#include<\tc\tpp\includ8 .c> 
extern void adopt (int k); 

extern void loginO, paintpO, palnts() 9 rtrn() ; 

extern void screenQ, survey ()» updtfO, varvaKint i, char val[80]) 

extern int addrep(char inmDUXPATH] , int place) ; 

extern void xeerpt(int iswitch); 

extern int idcheckO; 

extern char* fn(char filenaae[9]) ; 

extern char* fn2(char filename [9] ) ; 

extern void ucmnd(char whence [7]), vcnmd(); 

extern FILE *&aps 9 *napp 9 *react» *title; 

extern struct ffblk ffblk; 

extern int output, updts 9 updtp, updtr, status; 
extern int wtl 9 wt2 9 vt3 9 vt4; /* title window corners »/ 
extern int wxl 9 wx2 9 wx3 9 vx4; /* screen/page window corners */ 
extern int vil 9 wi2,wi3 9 vi4; /* interaction window corners */ 
extern int vt I 9 wf2,vf3 9 vf4; /* footer window corners */ 
extern int uhandle; 

extern int ips 9 ps 9 nsptot[2] f nspid[2]; 
extern int spfirst[2] 9 spies t [2], spfcode[2]; 
extern int newpage, usepage; 

extern int xval[30], yval[30] , lval[30] 9 nval; 

extern char sparray[7800] , response [240] 9 pagedata[PAGELEN] ; 

extern char sp[2] [MAXSP] [13] 9 sptext [2] [10] 9 spchar [2] [2] ; 

extern char t [80] f tnok[80] , r[2000] 9 idch[13] ; 

extern char drive [MAXD&XVE] 9 pf ile [HAXFILE] 5 

extern char pathOfAXDIR] , cwd[HAXDIR] ; 

extern char fname[HAXPATH] ; 

extern char dun [160] ; 

extern char userid[5] 9 varid[6] 9 usersinfo[USERSLN] ; 
extern char *ptr 9 whence [7]; 
extern char timbuf [27] ; 



#include <\tc\tpp\extern.c> 

/* Adopt implements a user's choice to adopt the organization 
and/or page contents of another user */ 
void adopt (int k) 
{ 

int i; 

/* Delete previous Uuserid segmend */ 

ips*k; 

zcerpt(2); 

il(splastW >= spfirstW) 

< 

nsptot [k]=nsptottk]-(splast W-spfirst DG+2) ; 

*or(i*spfirst[kl-l; Ksnsptot [k] ; i++) 

strcpyUspW [i] [0] ,*sp[k] ti+splast tk]-«pfirst[k]+2] [0]) ; 



/* Append adopted (idch) version under userid rubric */ 
«trcpy(Jt8p[k] [nsptotDOJ [0] t "U") ; 
strcat(*sp[k] CnsptotWl [0] f userid) ; 

ipsek; 
xcerpt(l); 

il(splast[k] < spfirstCk]) 

{ 

print! ("Hull set adopted. What next? »); 

return; 

} 

for(i=splirstD0; i<°splastD0; i++) 

strcpy<Asp[k3 [nsptot 00+i-spfirst M+l] [0] , ftspW [i] [0] ) ; 

nspt ot tk] snsptot [k] +splast DO -spf irst [k] +2 ; 

il(k == 0) «pdts*l; 

else updtpsl; 

updtf<); 

> 
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/* Nodule addrep handles logic common to the 

add ('A 1 ) and replace OR') command* */ 

int addrep (char fnm[HAXPATH] 9 int place) 
{ 

int i, handle; 

int muni, nnmr , pgdptr; 

int left[VMAX] 9 right [WAX]; 

char convi[3] ; 

char 8pname[13] 9 placech[3] , ich[3] 9 response [80] ; 

strcpy (spname f tap char [pe] [0] ) ; 
itoa(place,placech v 10) ; 
street (spname ,placech) ; 
strcpy(fnm 9 drive) ; 
street (fnm, spname) ; 
street (fnm f ".«); 
street (fnm 9 idch) ; 



/* need to generate alternative name? */ 
if ( f indf ir s t ( f nm , Mfblk 9 spf code [ps] ) == 0) 
{for(i=i; i<=MAIIFILE; i++) 
i 

strcpy (spname .tspchar [ps] [0] ) ; 

street (spname 9 "i") ; 

itoa(i 9 ich 9 10); 

street (spname ,ich) ; 

strcpy (Inn 9 drive) ; 

street (fnm, spname) ; 

street (fnm 9 ". M ); 

street (fnm, idch) ; 

if (f indf irst(fnm 9 *ffblk 9 spf code [ps]) 0) goto avail; 
gotoxy(l,l); 

print* ("User %n already has Xd new %ss.\n M 9 

idch 9 NAXIFIL£ 9 toptext [ps] ) ; 

printf ("Add and Replace unavailable . \n" ) ; 

printf ("Try e different command:"); 

return(-l); 

> 

avail: ; 



1TV *-*f AW»Sf 



89 



if(p«==0) 
{ 

mkdirdnm) ; 

/• priatf ("addrepl, Ixun: !&s",fnm) ;rtrn() ; xap */ 
strcpy(fnm, drive) ; 
strcat (fnm , spname ) ; 

strcat (fna,"."); 
strcat (fnm, idch) ; 
■treat (fan, M \V a ); 
strcat (fnm,'* title") ; 
strcat(fnm,"."); 
strcat (fnm, idch) ; 

/• printf ("addrep, fnm: Xs'Man); zap */ 
handle =opan ( inn , 0_RD VR I O.CREAT , S. READ I S.IVRITE) ; 
if ((output >=&) ftft (handle < 0)) 
{perrorO'nev icreen title : w );rtrn();} 
gotoxy(l,l); clrecrO; 

print f ("Enter title for your new screen: \n") ; 

rewind(stdin) ; 

scanf ( , 7.[-\n]" .response) ; 

write (handle , response , strlen(response)+l ) ; 

close (handle) ; 

} 

else 

{ 

vindov(l ,1,80,1); gotoxy(32,l) ; 

printf ("JCs %& of Xd^.ptextCps], place t nspid[ps]+l); 
strepy(fnm,drive) ; 
strcat (fnm, spname) ; 
strcat (fnm,"."); 
streat (fnm, idch) ; 

handlesopen(f am,0JU>URl 0_CREAT,S_IREAD IS.IWRITE) ; 

If ((output >= S) ftft (handle < 0)) 

{perror ("lew page : M ) ;rtxn() ;} 

inp: window(wil,wi2,wi3,wi4); gotoxy(l,l); 

printf ("Enter contents of your new page (0 and carriage return to end):"); 

window (wxl,wx2,wx3,wx4) ;clrscr() ; 

rewind ( Btdin) ; 

scanf ("%[-«] '\pagadata) ; 

rewind(stdin) ; 

write (handle ,pagedat a , s trlen (pagedat a) +1 ) ; 
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close (handle); 
usepage=place; 

lor (nnml=0, numr=0, pgdptmO; pgdptr<strlen(pagedata) ; pgdptr++) 
{ 

if (pagedata[pgdptr] *{') 
{lefttnuml3«pgdptr; numl+4;} 
if (pagedata[pgdptr] « »}>) 
{right [raanr]«pgdptr; xnunr++;} 
> 

if (zraml != numr) 

{printf ("Mismatched number of »{' (%d) and »}.' Wd)", 
nual, numr); goto inp;} 

it (numl > VHAX) 

{printf ("Too many variables: %d > Xd!" v nual, VHAX); 
goto inp;} 

lor (i*0; i<nual; i++) 
{ 

street (r , spname) ; 
il(strcmp(ideh,"") 0) 
{■treat <r, N . N ); ■trcat(r t idch);> 
strcat(r f M V •'); 

■trepy(convi,itoa(i+l ,eonvi,10)) ; 
■treat (r,convi); 
■treat (r," •»); 

■trncat(r t ftpagedata[left[i]+ 1] .right [i]-lelt[i]-l) ; 

■trcat(r,"\n M ); 

> 

il (muni > 0) 
{updtr»l; updtf();> 

window (wil,wi2,wi3,wi4) ; 

clrscrO; 

> 



strepydnm, spname) ; 
if(strcmp(idch i MM ) !« 0) 
{ 



strcatdnm,"."); 
•treat (inm,idch) ; 
> 

if(psssO) updts&l; else updtp=l; 

return(l) ; 
> 
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/* Nodule fn returns a file path, appending idch */ 

char* In (char filename [0]) 
{ 

Btrcpy (f name , drive) ; 
b treat (1 name .filename) ; 
strcatCfname,"."); 
a treat (f name 9 idch) ; 

/♦ printf (»\nfn. use: V.s (drive: f /.s name: %* idch: %s).\n", 
f name , drive , filename , idch) ; * / 
returnd name) ; 
> 

/* Module fn2 returns a file path, appending userid */ 

char* fn2(char filename [G]) 
i 

strcpy(f name, drive) ; 
street (f name »f ilename) ; 
atrcat (f name »"."); 
strcat (f name , userid) ; 

/* printf ( M \nfn, use: %n (drive: %s name: v /.s idch: %s).\n" f 

f name 9 drive , filename 9 idch) ; */ 

return(fname); 

> 

/* Module idcheek returns 1 if user is in own setup, otherwise -1 */ 

int ideheckO 
{ 

if (strcmpi(idch,userid) == 0) retuzn(l); 
else 

{ 

gotoxy(l,l); 
clrscrO; 

printf ("Changing another user's setup is disallowed. To adopt this user's setup,") 

printf ("\ntype U%s from Screen mode. lev command: ", userid); 

return(-l); 

> 

> 
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/* Module login identifies a new or previous user */ 

void login () 
{ 

int i, nbytes, offset; 
char *ptrl , ens [80] ; 

uhandlesopen ( "users 11 , 0.RDVR 1 0. CHEAT » S.IREAD I S.I WRITE) ; 
if (uhandle < 0) 
{perror ("users: ••); 
exit (status);} 

printf ("\nEnter user ID of up to three characters: "); 
•canf(» t / t s",userid); 

if (•trcmp(userid, ,, #l ,, )==0) {strcpy(userid, ,,H ) ;return;} 

nbytes = read(uh8ndle,userslnfo,USERSLN); 
offsetsO; 

while (off set < nbytes) 
{ 

ptreftusersinf o [offset] ; 
if ((strncnp(ptr,tn>ELXM,l) 0) 
ftt(Btrcmp(ptr+l,userid) ==0)) 

{ 

of f seteof f set+ strlen(ptr)+ 1 ; 

if (strncinp(*users info [offset] t 0DELIM f l) != 0) 

printf ("\nHello, %s\n M t *usersinf o [offset] ) ; 

delay(760); 

close (uhandle); 

return; 

} 

else 

of f seteof f set+strlen(ptr)+ 1 ; 
} 



/* Id not yet logged. Log it with other info */ 
strcpy(ana,TOELIM) ; 
strcat(ans f u8erid) ; 
vrite(uhandle f ans 9 8trlen(ans)+l) ; 

printf ("\n\nPlease enter your name:\n"); 



YYKJ yHf 1UUJ/ 



94 



rewind(etdin) ; 

•canlC'XC^XxO'San*); 

write (uhandle, ens, strlen(ans)+l) ; 

printf("\n\nType 1 for academic, 2 tor professional, 3 lor government: "); 

revind(stdin) ; 

scanf(*7.[~\n]",anB); 

write (uhandle ,ans ,strlen(ans)+l) ; 

fer(i=l; i<=5; i++) 

printf ("\n\nType %d of 5 supplemental info lines (e.g., phone, address) :\n M ,i); 
rewind ( s tdin) ; 
scanf ( t 7.t*\n] M ,ans); 
write(uhendle,ans,strlen(ans)+l) ; 

} 

close (uhandle) ; 
} 
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/* Module paintp updates the screen in page node +/ 

void paintp () 
{ 

int index, i, j, pgdptr, numl, numr 9 skiplin, firstscr 
int left [30], right [30]; 
int xpos,ypos; 
int idtot, ndash; 

char idl [8] 9 id2 [8] 9 id3 [8] ; 

char ppath [H AXPATH] ; 

char tinfo[80] 9 count C3] .fx [80] ,val[80] ; 

FILE *pg; 

nspidCps] =0; spfirst [ps]=0; splast[ps]=-l ; 

ips»ps; 

xcerpt(l); 

nspid[ps] espiast [ps] -splirst [ps] 41 ; 

/* Screen heading */ 
window(l 9 l ,80,26); 
clrscrO; 

printf ( "VnPrivatization Planner (tn) 91 ) ; 
gotoxy(32,l) ; 

if (nspidCps] «s o) usepage = 0; 

if (usepage > nspidCps]) usepage = 1; 

if ((nspidCps] > 0) ftft (usepage < 1)) usepage * 1; 

printf ("%s %d of Xd",sptext [ps] 9 usepage, nspidCps]) ; 

gotoxy(57,wt2-l) ; 

tine(tisbuf ); 

printf ("Xs" 9 cti»e(timbuf)) ; 

/* Screen title */ 
gotoxy((80-strlen(t))/2 9 vt2) ; 
printf ("%s\n",t); 

strcpy (idl , "default 1 *) ; 

if (strcnp(userid, M ") o) strcpy ( idl , us erid) ; 
strcpy (id2,"default") ; 

if(strcmp(idch 9 "") ! = 0) strcpy ( id2 9 idch) ; 
strcpy (id3 , "default") ; 

if (strcapOrarid,"") != 0) strcpy (id3 9 var id) ; 



96 - 



45 



idtot=strlen(idl )+strlen(itt)+strlen(id3) ; 
ndaoh= ( 80-47-idtot ) /2 ; 
for(i=l; i<=ndash; i++) 
printf ("-"); 

printf ("You are # /.s f looking at the %» version ," 
"with '/.b values. " 9 idl 9 id2 9 id3); 
for(i=l; i<«ndash; i++) 
print* ("-"); 

/* Page contents */ 

if (splastlps] spfirst[ps]) /* any pages? */ 

{ 

strcpy(ppath, drive) ; 

street (ppath, top [ps] [spf irst [ps]+usepage-l] [0] ) ; 

printf ("paintp: sp %s " 9 top [ps] [spf irst [ps]4usepage-l] [0]); /+ zap */ 

pg=iopen(ppath t "r+") ; 

strcpy(pagedata t "") ; 

f read(pagedata 9 l V PA6ELEN 9 pg) ; 

fclose(pg); 

xpossvzl; ypos*wx2; nvalcO; 

f or (nualsO f numr=0 ,pgdptr=0 ;pgdptr<strlen(pagedata) ;pgdptr++) 
{ 

if (pagedat a [pgdptr] ~'V) 
< 

left [nuffll] =pgdptr ; 
xval [nual] =xpoa ; 
yval [nual] =ypos ; 
numl++; 
> 

if (pagedata [pgdptr] « » } » ) 
{right [numr] =pgdptr ; nnmr++;} 

if (strncmp(apagedata[pgdptr] , M >= 0) 

xpos++; /* non-printing Ctrl character? */ 

if((zpos > vt3) || (strncmp(ftpagedata[pgdptr] 9 "\n" 9 l) == 0)) 

{xpos=l; ypos++;} 

> 



if(numl != numr) 
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gotoxy(vil,vi2); 

print* ("mismatched number of »{» C/d) and »>» (%d) M , 

nnml v numr); 

> 

else 

{ 

nval=numl; 

for(i=0; i<imml; i++) 
{ 

lval [i] =right [i] -left [i] +1 ; 
varval(i,val); 

strnset(fcpagedata[lef t [ij+l] t » » t lvalti]-2) ; 
for(j=left[i]+l; j<=right[i]-l; 
Uf(valtj-left[i]-i] == »\0') break; 
pagedata[j]n V al[j-left [i]-i] ;} 

> 
} 

gotoxy(vxl f ux2) ; 
print f ( , 7.B",pagedata) ; 
> 

/* footer */ 

gotoxy(vfl,vf2); 

printf("%B" f 

" Page Add Replace Delete Values Eval Screen User Help Quit"); 
gotoxy(vfl,vf2+l); 
strcpydx, 

" 0 mode [id]"); 

if(nspid[ps] < 1) print* ("Jls'\fx); 
else 
{ 

sprintf(fx, 

- 0-3i2d 1-X2d 1-X2d *l-it2d B0 de [id]", 

nspidCps] ,nspid[ps] ,nspid[ps] 9 nspid[ps]) ; 
printf("%s",fx); 
/* gotoxy(80 t 25); 

printf(""); anto-eject for hard copy of screen ♦/ 

} 

> 
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/* Module paints updates the screen (in screen node) */ 

void paints () 
{ 

int index, i, il, 12, skiplin, tirstscr; 
int idtot, ndash; 

char id! [8], id2[8], id3[8]; 

char tpathDUXPATH] , *evdext; 

char tinf o[80] , count [3] ,sx[80] ,fx[80] ; 

FILE *ti; 

nspid[ps]=0; splirst[ps]=0; splast[ps]s-i; 
ipssps ; 
xcerpt(l) ; 
nspidCps] ssplast [ps] -spf irst [ps] +1 ; 

/* Screen heading */ 
vindov(l t l t 80,2B); 
clrscrO ; 

printf ("\nPrivatization Planner (tm)") ; 

gotoxy(57,vt2-l); 

time(timbuf ) ; 

printf ("Xs ,> p cti&e(timbttf)) ; 

/* Screen title */ 
gotoxy((80-strlen(t))/2,vt2) ; 
printf("Xs\n",t); 

strcpy (idl , "default") ; 

if(strcap(userid," H ) != 0) strcpy (idl.uaerid) ; 
«trcpy(id2, "default") ; 

if (strcmp(idch,"") !* 0) strcpy(id2 # idch) ; 
strcpy (id3 , "default") ; 

if (strcap(varid,"") 0) strcpy (id3 , vaxid) ; 

idtot=strlen(idl )+strlen(id2)+strlen(id3) ; 
ndash=(80-47-idtot)/2; 
for(i=l; i<sndash; i++) 
printf ("-"); 

printf ("You are Kb, looking at the %b version," 
"with 7.s values . " , idl , id2 v id3) ; 
for(i«l; i<=ndash; i++) 



print f (■•-•'); 



gotoxy(vxl 9 vx2); 

printf(" , /.s , \ M S Next Higher Screen (SO for Root)"); 

if (spies t[ps] < spfirstCps]) goto skpdir; /* any subdirs? */ 



if(nspid[ps] == (wx4-wx2)) sfciplin=0 ; 
else skiplin=l; 

f irstscr=l ; 

if(nspid[ps] > (wx4-wx2)) 
{ 

gotoxy(vil,vi2); 

printf("Too many screens to fit!\n"); 

print f ("Enter number of the first screen to display: "); 

scanf ( "*/,d" , first scr ) ; 

} 

il=spf irst [ps] +f irstser-1 ; 
12=min(il+vx4-wx2-l , spies t [ps] ) ; 

for <i=il; i<= i2; ±++) 
< 

index*i-il+i; 

strcpy(tpath t drive) ; 
8trcat(tpath 9 ftsp[ps] [i] [0] ) ; 
■treat (tpath, "\\") ; 
■treat (tpath, "title") ; 

/* print f ("paints sp, tpath: %b XB" f Jfesp[ps] [i] [0] t tpath); */ 

cwdext=strrchr(fesp[ps] ti] [0] f ' . ') ; 
/* printf(" evdext: %■ " 9 cvdext); zap */ 
if((cvdext != VULL) kk (strlen(evdext) <= 4)) 
street (tpath 9 evdext ) ; 

/* print f ("paints tpath: %s" 9 tpath); rtrnO; zap */ 

ti*f open(tpath 9 M r+") ; 
strcpy(tinf o 9 tnok) ; 
f read(tinf o , 1 ,77 9 ti) ; 
fclose(ti); 
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strcpy(sx,"S"); 

strncat ( sx t it oa( index , count , 10) , 2 ) ; 

•treat (ex," ")5 

strncat (sx,tinfo, 76) ; 

gotoxy (wxl t wx2+index+skiplin) ; 

print! ( m Xb m ,bx); 

> 

•kpdir: 



/* footer */ 
gotoxy (v! l,v!2); 
print! ("JIb", 

"Screen Add Eeplace Delete Title Eval Page User Help Quit 11 ); 
gotoxy(wf l,v!2+l); 
strepydx, 

•• o node [id] 1 '); 

if(nspid[ps] < 1) print! ("%bMx); 
else 

sprint! (!x, 

» 0-X2d l-%2d l-%2d 1-Jl2d mode [id]" t 

nspidCps] ,nspid[ps] .nspidCps] ,nepid[p8]) ; 
print!("%8'\!x); 
> 



> 



void rtm() 
i 

/+ elicit carriage return bo message can be seen */ 
printf ("Type c and return to continue: *•); 
revind(stdin) ; 
scant ("%8" f dum); 
> 
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/* Module Survey determines what files are available 
upon entry to a new screen, flagging missing ones */ 

void survey () 
{ 

struct fcb fcb; 

char *ptr, *cvdext, titfnm[10j; 
char but [14] , convrt [9] ; 
int nmap8 9 nmapp, i; 

if (output >= 3) printf ("survey V.s \n",getcwd(cwd 9 HAXDIR)) ; 

strcpy(titfnm f "title.") ; 
get«d(cvd,MAXDXR); 

cvdext=strrchr(cwd 9 '.'); /* e.g., (.)abc */ 
if((cwdext != HULL) ft* (strlen(cwdext) <= 4)) 
street (titfnm , cwdext+1 ) ; 

/* printfO'Jis y.s y.s" 9 cvd 9 cvdext,titfna);rtrn(); zap*/ 
fcloseallO; /* clean slate */ 

if (((mapssfopen("nap8 9> v n a+"))»HULL) ft* (output >« 3)) 

{print f ("Cannot open HAPS.Xn"); 

rtrn();> 



if (((nappsfopen( ll napp" 9 ,l a4"))-«HULL) ft* (output >= 3)) 

{print f ("Cannot open MAPP.W); 

rtrn();> 



if (((react=fopen("react" 9 M a+"))s=HULL) ftft (output >«= 3)) 

{pr int f ("cannot open react.W); 

rtrn();> 

if (((title=fopen(titfnm > ,, a+ M ))==inJLL) kt (output >= 3)) 

{printf ("cannot open title. WO; 

rtmO;} 

nsptot [0] =0; 

if (maps != HULL) 

{ 

nmaps=fread(sparray ,1,2400, maps) ; 
rewind (maps) ; 
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ptrsstrtokUparray," \n"); 

lor (i=0; ptr != HULL; i++) 
i 

strcpy(*sp[03 [i] [0] ,ptr) ; 
ptr=strtok(HULL f " \n"); 

if(Btrncap(ft8p[0][i]t0], M U» t l) « 0) continue; 

il(lindfirBt(ft8p[0]Ci][0] > «ftlk > FUIREC) I* 0) 
{printf ("cannot find %* . " ,*sp[03 [i] tO] ) ;rtrn() ;> 
> 

nsptot [0]=i; 
} 

strcpy (sparray f HULL) ; 

nsptot [13=0; 
if(napp != HULL) 
{ 

nmapp=fread( sparray ,l,2400,aapp) ; 
rewind (mapp) ; 

ptrsstrtok(spaxray," \n"); 

lor (i=0; ptr != HULL; i++) 
{ 

strcpy (asp [1] [i] [0] »ptr) ; 
ptrsstrtok(HULL," \n M ); 

ii(strncmp(a8p[l]Ci][0] f "U" f l) 0) continue; 

if(findfirst(asp[l]Ci][0] 9 Mfblk 9 0) 1= 0) 

{print! ("cannot find %s. " 9 top[l] [i] [0] ) ;rtrn() ;} 

> 

nsptot [l]-i; 
} 

strcpy (sparray ,HULL) ; 
strcpy(t 9 tnok); 

if(((title=fopen(titfnm 9 "r*")) == HULL) ftft (output >= B)) 
print! ("cannot open file %s", touf); 

if (title !* HULL) fread(t ,1,80, title) ; 
revind(title) ; 

> 
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void uemnd(char whence [7]) 
{ 

FILE *title2; 

int i 9 idexist, nbytes, offset; 
char ufile[HAXPATH] ; 

getcvd(cvd 9 MAXDIR); 
strcpy(uf ile t path) ; 
•treat (ufile,"\\"); 
street (utile, "users 91 ) ; 

uhandle=open(ufile 9 0 JIDVR I O.GREAT f S.IREAD I S.IVRITE) ; 

lseek(uhandle 9 0 9 SEEK_SET) ; 

nbytes = read(uhandle 9 usersinfo,USERSLN) ; 

close (uhandle) ; 

chdir(cvd); 

if (strlen(respoxise) ==1) /* just plain "U" */ 

gotoxy(l 9 l); clrscrO; 

printf( M Do you want the default "); 

if(psssO) printf ("organization and contents (T or N)T 

else printf ("values (T or H)? "); 

rewind ( st din) ; 

•canf("5is" f dua); 

if (strncmpi(dum 9 "T"»l) == 0) 

{ 

if(pBssO) strcpy(idch 9 ""); 
else strcpy(varid,""); 
goto start; 
} 

offsetsO; 

while (offset < nbytes) 

{ 

ptrstasersinfo [offset] ; 

if (strncmp(ptr 9 in>BLXM 9 l) « 0) 

{ 

/* if no change 9 disregard */ 

if((ps— 0) tft (strcop(idch,ptr+l)«0)) goto skipsa&e; 
il((p»==l) kk (strcnp(varid,ptr+l)»0)) goto skipsane; 

gotoxy(l.l); clrscrO; 

printf ("Userid* %s",ptr+l); 

printf ( " Names %s\n" 9 ptr+strlen(ptr ) + 1 ) ; 
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print f ("Select this user's "); 

if(ps==0) print f ("organization and contents (Y or H)T "); 

else print! ( "entries lor variable values (Y or H)? M ); 

revind(stdin) ; 

scanf("%s" f dum); 

if (strncmpi(dum,"Y",l) 0) 

{ 

if( p8S ,=0) 

{ 

if (strcmp(ptr+i,userid)**0) goto adopt; 

strcpy(idch,ptr+l) ; 

> 

else strcpy ( varid t ptr+l ) ; 

goto start; ^ 
> m 

> 

skipsame : of f set-off set+strlen(ptr)+l ; 
} 

/* Future mod: splat all users for random not serial choice */ 
gotoxy(l,l); clrscrO; 

print f ("Ho more users! Try another command: "); 

goto cmnd; 

> 

else /* id appended */ 

{ 

idexist=0; 
off set s0; 

while (offset < nbytes) 

{ 

ptrstasersinfo [offset] ; 

if ((strncop(ptr,UDELIM,l) == 0) 

M(strcmp(ptr+l,*response[l]) 0)) 

<idexist=l; break;} 
off set-off set+strl«n(ptr)+l ; 
> 

if(idexistssO) 
{ 

gotoxy(l»l); clrscrO; 

print f ("Id %b isn't available. Try another command: "Response [1] ) ; 

goto cmnd; 

} 



if (ps==l) 

{ 

strcpy(varid»taesponae[l]) ; 

goto start; 

} 

if(strcinpi(uBerid,ftresponse[l]) != 0) goto term; /♦ own id entered */ 

/♦ adopt HAPS.idch ?T */ 
adopt: gotoxy(l,l); clracrO; 
ipseO; 
xcerpt(2); 

if(splast[ips] < spf irst[ips]) 
print f ("You do not yet"); 
else printf("You already"); 

print f(" have a personal setup for the SCREEN layout."); 
clreolO ; 

if(strcmpi(idch,"") != 0) strcpy(dum.idch) ; 
else strcpy(dum, "default (std)"); 

printf("\nDo you want to adopt the 7.s version (Y or N)T ",dum); 
clreolO; 
scanf("y.8" f duin); 
if(strncnpi(duin > "Y ,, t l) == 0) 
i 

adopt (0); /* adopt organization */ 
/* adopt screen title as veil */ 
unlink(fn2("title")) ; 

«(((title2=fopen(fn2("title") f »w+")) HULL) 

kt (output >= 3)) 

{ 

printf ("Cannot open title.userid.Xn") ; 

rtznO; 

> 

revind(title2) ; 

t writ e ( t , 1 , 80 , t itle2) ; 

> 

/* adopt HAPP.idch ?T */ 
gotoxy(l,l); clrscrO; 
ip»=l ; 
xcerpt(2); 

if (splasttips] < spfirstCips]) 
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printf("You do not yet"); 
else print! ("You already"); 

printf(" have a personal setup lor the PAGE layout."); 
if(8trcmpi(idch/ ,H ) !* 0) strcpy (dum.idch) ; 
else strcpy (dum, "default (std)"); 

printf ("\nDo you want to adopt the */.s version (T or N)? ",dum); 
scanl("y.s" # dum); 
if (strncmpi(dum,"Y"»l) == 0) 
adopt (1); /* adopt contents */ 

term: if (ps == 0) strcpy(idch,ptr+l) ; 

start: strcpy (whence /'start"); return; 
prompt: strcpy ( whence , "prompt" ) ; return; 
cmnd: strcpy (vhence 9 "cmnd" ) ; return; 



> 
} 
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/+ Module updtf updates the naps, aapp and react files at appropriate */ 

void updtf () 
i 

int i; 

if(updts != 0) 

strcpy(sparray /'") ; 

for(i*0; i <= nsptot[0]-l; i++) 
{street (sparray,ftsp[0] [i] [0] ) ; 
s treat (eparray," ");} 

f close (maps) ; 
unlink ("maps"); 

if ( ( (maps=f open( "maps" , "w+'O )==NULL)tt (output>=3) ) 

{printf ("cannot create new MAPS.Vn") ;rtrn() ;} 

f write (sparray,! ,strlen(sparray)+l t maps) ; 

strcpy (sparray 9 KULL) ; 

updts=0; 

} 

if(updtp Is 0) 
{ 

strcpy(sperray,«") ; 

for(i«0; i<= neptot[l]-l; i++) 
{strcat(sparray ,*sp[i] [i] [0] ) ; 
s treat (sparray," ••);} 

f close(mapp) ; 
unlinkC'napp"); 

if ( ( (mapp*f open( "mapp" , "w+") )==*ULL)WK output >=3) ) 

{printf ("cannot create new HAPP.\n") ;rtrn() ;> 

f vrite(sparray f 1 ,strlen(sparray)+l, mapp) ; 

atrcpy (sparray ,NULL) ; 

updtpsO; 

} 

if (updtr != 0) 

f seek (react, 0,SEEK_END) ; 

f write (r , 1 t strlen(r) +1 t react ) ; 

8trcpy(r »UD£LIM) ; 
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■treat (r t UB«rid) ; 
■treat (r,"\n M ); 
updtr=0 ; 
return; 
} 
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void varvaKint i, char val[80]) 
{ 

char reactbuf [160] ; 
int nfields, right id; 

■trcpy(val, M "); 
f aeek (react ,0 ,SEEK_SET) ; 
•trcpy (reactbuf , m< ) ; 
right id=0; 

while (1 get b (reactbuf ,160 .react) »= HULL) 

{ /* allow for \0 character prefix */ 

if (strncnp(taeactbuf [1] ,TOELIM t l) == 0) 

{if (strncmp(*reactbuf [2] t wid,strc8pn(fereaetbuf [2] \n u ))**0) 

rightid=l; 

else right id=0; 

continue;} 

else 

{ 

if (right id != 1) continue; 
ptrsstrtok(reactbuf ," \n"); 

if (strcmp(ptr t *sp[ps] [utepage] [0] ) 1= 0) continue; 

ptr=Btrtok(NULL f " \n M ); 

if (•^^(ptr,^") !* 0) continue; 

ptr=8trtok(NULL»" \n w ); 
if(atoi(ptr) != i+1) continue; 

ptr&8trtok(lTOLL, "\n") ; 
•trncpy(val > ptr,lval[i]-2) ; 

> 
} 



return; 
} 
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void vcnnd(char whence [7]) 
{ 

int i.j; 

char vbuf [160] , convj [3] ; 

for (i=0; i<nval; i++) 
i 

/* currently assumes value for variable on tingle line */ 
gettext(xval[i] , yval[i] ,xval[i]+lval[i]-l,yval[i] , vbuf ) ; 

tox (j*l; j<=lval[i]; 

vbuf [2*j-l]=vbuf [2*j-i] I BLIHK; 

puttext(xval[i] ,yval[i] ,xval[i]+lval[i]-l t yval[i] ,vbuf ) ; 
gotoxy(l,l); clrscrO; 

print 1 ("Do you want to enter a value for this variable (T or K)? "); 
rewind (stdin) ; 
•canf ("%s",dum); 

if (strncmpi(dum,"Y",l) != 0) goto noblnk; 
gotoxy(l 9 l); clrscrO; 

print f ("Enter value (\ M for the sane):\n"); 
re wind (stdin); 

printf ("{»); gotoxy(lvalli] ,2); printf (»>»); gotoxy(2,2); 

•canf("y t [-\n3",duin); 

if (strcmp(dum,"V ,M ) •== 0) 

i 

tox (j=l; j<=lval[i]-2; j++) 

dum[j-i]«vbuf [2*j]; 

> 

if(strcmpi(userid,varid) « 0) 
{ 

tox (j=l; j<=lval[i]-2; 

if(j <= strlen(dua)) vbuf [2*j]*dum[j-l] ; 

else vbuf [2*j]*> »; 

} 

/* apend to buffer for react file */ 
strcat (r f tsp[ps] [usepage] [0] ) ; 
■treat (r," V "); 

strcpy (convj ,itoa(i+l , convj ,10)) ; 
street (r, convj ) ; 
strcat(r," "); 
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street (r,dum); 

street (r,"\n u ); 
npdtr=l ; 

npdtK) ; 



/* update screen (turn off blink) */ 
noblnk: lor (j=l; j<=lval[i]; j++) 
vborf [2*j-l]ovbnf [2»j-l] & (*BLIHK) ; 

puttext(xval[i] ,yval[i] ,xval[i]+lval[i]-l ,yval[i] ,vbnl) ; 
> 

return; 



> 
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/* Nodule xcerpt identifies id-specific naps or mapp entries */ 

void xcerpt (int isvitch) 
{ 

char idcmp [6] ; 

int i, first, last; 

gotoxy(vil»vi2); 



first « 0; 
strcpy(idcmp l M U"); 

if (isvitch « 1) strcat(idcmp,idch); 

else street ( idemp ,userid) ; 

for(i*0; i<nsptot[ips]-l; i++) 

if (stremp(ftsp[ips] [i] [0] ,idcnp) «== o) break; 

first«=i+l; 

for(i=first; i<=nsptot [ips]-l; i++) 

if (strncmp(*sptips][i][0] > ,, U" > l) » o) break; /* ftsp[ips] [n] [0]«don»t care */ 
lastsi-l ; 

spf irst [ips] =f irst ; 
splast [ips] slast ; 



return; 
> 
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DF Disposition File 



The serial Disposition File (DF) contains financial records to be transmitted to 
financial institutions which will act as custodians of the specified assets. It xs 
created by module PASSS and processed by module DISPOSE (see Appendix 

2). 



Format: 

financial institution ID codc:tcdpicnt ID code: 
recipient name:address:phone:supplementary name: 
assetl:amountl: ... asset ntamount n 



Examples: 

S1100100FNMXYFNBR:19460630ERFXYCDEF: 

Ellen Right:1040 Oak Terrace;Anywhere:555-1515:Smith: 

PAYOUT;FNBR;940101;D;N;M:4.32%;1;986:250,000 

(Financial institution FNBR is custodian of an annuity for individual ER, in the 
amount of 985 (local currency) to be paid monthly until her death, without right 
of survivorship. This amount was calculated from actuarial table #1, assuming 
an implicit interest rate of 4.32% and an initial investment of 250,000 (local 
currency).] 

51100021MLMMLPF:19630704MRMXYBCDE:STLI:1000: 
Michael Right:1040 Oak Terracc;Anywhere:555-1515:T*Tn: 
SMU:1:DLEVR;01;8%:10,000 

[Financial institution MLPF is custodian, on behalf of individual MR, of 1000 
shares of STM, 1 SMU and 10,000 (local currency) of 8% debt of LEVR which 
matures in the year 2001. 



Certain assets such as debt and annuities (DXXXX, DIXXXX and PAYOUT) 
are automatically included in the Disposition File if the acronym embedded in 
the asset does not specify the government itself. 

Other assets, such as Stock Market Units, enterprise stock, foreign currency 
(SMUs, EXXXX, FCXX) or government debt are included in the Disposition 
File only when so directed by a valid TRANSFER command (sec Appendix 3). 
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October 15, 1992 Confidential Draft 



Note: 

The asset amount must be in number of shares, number of SMUs, units of foreign 
currency, face value of debt (in local currency) or periodic annuity payments (in 
local currency)- The asset amount cannot be expressed as a percentage of the 

portfolio contents. 
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DFXXXX Disposition File: Excerpts 

The serial Disposition FUe: Excerpts (DFXXXX) is generated by module DIS- 
POSE and contains the information to be transmitted to a particular custodial 
financial institution. 

Format: 

Financial institution ID code:name:address:phone:supplementary name 

Recipient #1 ID code:name:address:phone:supplementary name: 
asset 1: amount 1: ... :asset ntamount n 

Recipient #N ID code:name:address:phone:supplementary name: 
asset l:amountl: ... :asset n:amount n 
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DOFF Delegation Offer File 

The serial Delegation Offer File (DOFF) contains a summary of all offers to del- 
egate investment authority over assets. It is created by module PASS2, and then 
used by module DELCOMP to 1: calculate the minimum delegate* compensa- 
tion thresholds, and 2: update file DORF with that information (see Appendix 

2). 



Record format: 

delegate* acronym:asset valuexompensation offer:: 



Examples: 
INVI:10,000:10%E:: 

[There was an offer to delegatee INVI to accept investment authority over 10,000 
(local currency) worth of assets (valued on the basis of price estimate #1 as 
generated by module PASS1), in return for 10% of subsequent earnings.] 

INVL100,000:.5%A:: 

[In this case, the delegation offer is for .5% of assets estimated to be worth 
100,000 (local currency).] 
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DORF Delegate* Order File 



The random access Delegatee Order File (DORF) contains, for each delegatee, 
its nonproprietary transactions and its minimum compensation threshold by 
assets and earnings. It is created by module DORFGEN (which precedes PASS1 
and posts nonproprietary orders), and then updated by module DELCOMP 
(which follows PASS2 and posts minimum compensation thresholds). It is used 
by modules PASS1, PASS3, PASS4 and PASS6 (see Appendix 2) to determine 
what transactions the delegatees direct for assets in -various portfolios. 



Record format (standard XDB format): 

transaction type:date enteredras of datetfield 1: ... tfield N:: 

The only transaction types posted are ACQUIRE, CANCEL, FILTER, IDENT, 
PERCENTAGE, REINVEST and WHEN (see Appendix 3). No proprietary 
transactions (relating to the delegatee'* own assets) are posted. Room is re- 
served at the end for DELCOMP to update it with a PERCENTAGE record 
incorporating the final minimum compensation. 
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EPRISE Enterprise File 



The random access Enterprise File (EPRISE) for a particular investment cycle 
contains, for each enterprise, its ID code (with embedded acronym), the number 
of shares held on the Privati*e! TAf system, and the dividend to be accrued per 
share and pricing information for the stock and any debt instruments. It is up- 
dated by module PASS1, which first scans the segment of the Transaction Data 
Base (XDB) containing enterprise transaction blocks to update EPRISE with 
information from DIVIDEND transactions. EPRISE is also updated by module 
PASS5, which posts any corrections to the numbers of shares resulting either 
horn TRANSFER transactions (resulting in decreases due to transmittals to a 
custodial financial institution) or from "ACQUIRE for assets received (VAL) W 
transactions (resulting in increases due to share issuance). Finally, during each 
of PASS1, PASS3 and PASS4, module PRICING updates EPRISE with the 
latest calculations of asset prices. 



File format: 

SMU label: # SMUs: total dividend:: 

First SMU enterprise ID code: # shares: dividend: 

stock price estimate #l:price estimate #2:final price: 

debt instrument #l:price estimate#I:price estimate #2:final price: 

••* 

debt instrument #N:price estimate #l:price estimate #2:final price:: 



Last SMU enterprise ID code: # shares: dividend: ... 

SMU2 label: # SMU2s: total dividend:: 

First SMU2 enterprise ID code: # shares: dividend: ... 

Last SMU2 enterprise ID code: # shares: dividend: ... 

UNSMU label: total # shares: dividend:: 

First UNSMU enterprise ID code: # shares: dividend: ... 

Last UNSMU enterprise ID code: # shares: dividend: ... 

Notes: 

1. While SMU2s can be created immediately, the list of identified SMU2 en- 
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tcrprises would remain empty until after the first privatization occuring after 
the date cut-off separating SMUs and SMU2s (see discussion in Appendix 4: 
SMU2). 

2. "UNSMU" enterprises are those not included in either SMUs or SMU2s. 
They can arise either from private formation de novo, or by taking a SMU or 
SMU2 enterprise private by making a tender offer for all shares. Such a tender 
offer would be feasible even for an enterprise held by the entire citizenry as part 
of their SMUs, by means of polling techniques implemented by module EVOTE. 
If the tender offer were successful, it could be implemented by executing a DIVI- 
DEND transaction corresponding to the total buyout price for shares remaining 
on the Privatize!™ system. 

3. It is possible to create a new UNSMU asset comprised of qualifying enterprises 
on the system as of a fixed date. Until then, "UNSMU" is an acronym rather 
than an asset, and the total number of shares in the UNSMU record represents 
the sum of shares in all UNSMU enterprises, rather than the number of UNSMU 
stock "baskets." 

4. In the context of the EPRISE file, the term "enterprise" includes tradeable- 
stock-based or debt-issuing organizations such as financial institutions. 

5. The price for an enterprise may be in the form •lower bound; upper bound" 
if the arbitrage between SMUs and synthetic bids and offers leaves a price gap 
between the highest bid and lowest offer executed for shares in that enterprise. 



ORDERS Order File 



This serial file contains a set of all the orders to sell one asset and buy another 
which are to be used by module PRICING to calculate asset prices. 



Format: 

ID code #1:: 

assetl:pricel:asset2:price2:amount2:: 

assetl:pricel:asset2:pricc2:amonnt2:: 

ID code #N:: asset l:pricel:asset2:price2:amonnt2:: 

assetl:pricel:asset2:price2:amottnt2:: 

Copies of this Me ate created by modules PASS1, PASS3 and PASS4 using 
Transaction Data Block (XDB) information processed by module XBLOCK. 
Module PRICING is then invoked to process ORDERS to calculate asset prices. 
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PRICES Asset Price File 



The random access Asset Price File (PRICES) contains price estimates and the 
final price for Stock Market Units (SMUs), foreign currency (FCDM and FCUS), 
debt of the government (eg., DLEVR, DILEVR and PAYOUT;LEVIL..). It is 
created and updated by module PRICING. 

Format: 

Investment cycle #1 price estimate #1 
SMU, SMU2(nulI), FCDM, FCUS 
government debt instrument #1 ... #n 

Investment cycle #1 price estimate #2 
SMU, SMU2(null), FCDM, FCUS 
government debt instrument #1 ... #n 

Investment cycle #1 final prices 
SMU, SMU2(null), FCDM, FCUS 
government debt instrument #1 ... #n 
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XDB Transaction Data Base 



The serial Transaction Data Base (XDB) is the central file of the Privatise!™ 
system. It contains transaction blocks comprised of transaction records asso- 
ciated with a single ID code. An ID record begins a transaction block, which 
continues up to a "new line" character or the end of file. 



File format: 



First ID record 

Transaction other transaction records 

Block "new line* character 

Second ID record 

Transaction other transaction records 

Block "new line" character 

Final ID record 

Transaction other transaction records 

Block End of file 



Transaction record format: 

transaction typeidate entered:as of date:fidd 1: ... :field N:: 



Field format: 

subfield 1; ... ;subfidd n 

Thus, transaction blocks are delimited by ID records and a "new line** character 
or end of file mark, transaction records are delimited by two contiguous colons 
fields are delimited by a single colon and subfidds are delimited by a 
semicolon There are no other delimiters. 

The Transaction Data Base is generated by module XACT (see Appendix 2). 
XACT allows input of any valid transaction records from any source (as le- 
gitimated by off-line procedures), including terminals or serial devices such as 
floppy disks or 8mm tape drives. 



In the caily stages of the update cycle of the Transaction Data Base, new trans- 
action data can be viewed as compartmentalized into "logical subfiles" depend- 
ing on their source, e*g.: ADB (Auction Data Base), CDB (Citisen Data Base), 
CHIDB (Charitable Institution Data Base), EDB (Enterprise Data Base), FIDB 
(Financial Institution Data Base), FORNDB (Foreign Investor Data Base), 
GDB (Government Data Base as subdivided by agency, e.g. PBDB Privati- 
sation Board Data Base), TDB (Testamentary Data Base). While this logical 
compartmentalbation" can be useful in facilitating input procedures, audit trail 
backups and ancillary processing applications making additional use of the data, 
it is nonetheless completely transparent to the Privatise! 3 ™ software. 

Module XACT maximally aggregates dispersed records for the same ID code 
into a single transaction block, and sorts the resulting transaction blocks, within 
the constraints of available memory and disk space. After an iterative sort 
procedure, the final result is a single, comprehensive, sorted XDB file. The final 
XDB file would typically be comprised of a series of 8mm tapes (or other high 
capacity storage media). 

The comprehensive, sorted Transaction Data Base (XDB) is the basic file which 
Privatise!™ processes (in five passes) in order to: 1. determine delegations 
of investment authority; 2. establish asset prices; 3. execute orders as appro- 
priate; 4. update portfolio valuations; and 5. generate the Disposition File for 
transmittal to custodial financial institutions. 



Note: 

The default numeric protocol is that a period denotes the decimal point and 
a comma V is ignored as merely a devise to format large numbers. This default 
can be overriden by editing Included Module - GLOPARM (see Appendix 2). 
For example, by editing module GLOPARM as follows: 

decpt = 7 
numfmt = V 

the defaults would be switched. 



undexlineAppendix 2: Software Modules 

Page 



25 


ACTUARY 


26 


AUCTION 


27 


DELCOMP 


28 


DISPOSE 


29 


DORFGEN 


30 


EGEN 


31 


EVOTE 


34 


PASS1 


35 


PASS2 


36 


PASS3 


37 


PASS4 


38 


PASS5 


40 


PRICING 


44 


XACT 


47 


XBLOCK 



Included Modules 

ACRONYM 

ANNUITY 

FINOK 

GLOPARM 

PRICES 

SPINOFF 

STRUCT 

TEXT 

XASSET 

XTYPE 



ACTUARY 



ACTUARY calculates periodic annuity payments. 



Input: 

ID-code, interest >ate, amount invested and PAYOUT subfields: begin; end; 
survive; frequency;implicit interest ratejaetaarial table #. 



Return: 

Amount of periodic payments, for posting to the last PAYOUT subfield. 



Processing Logistics: 
Called internally by PASS5. 



Module logic: 

From the ID code and PAYOUT subfield "begin", ACTUARY determines the 
number of years (including fractional part) in the future of the first payment. 
The present value of a first payment of 1 is then calculated from the implicit 
interest rate. That present value is attenuated by the probability of survival 
according to the specified actuarial table if the ID code specifies an individual 
and the PAYOUT survive subfield was not set to S. The probability of survival 
is calculated from male and female lists of year-to-year survival probabilities. 
(Note that if survival probabilities are differentiated by sex, where females tend 
to be longer-lived their annuity payments would be smaller, magnifying any 
gender gap where females tend to have lower incomes. On the other hand, 
failing to distinguish between the sexes by using the same values in the male 
and female survival probability lists could reduce the incentive for males to 
invest in annuities.) 

The present value of subsequent payments, until the end date or until the proba- 
bility of survival becomes negligible, are progressively included into a cumulative 
present value. Finally, the amount of the periodic payments is calculated by di- 
viding that cumulative present value (associated with periodic payments of 1) 
into the amount invested. 



AUCTION 



AUCTION supports the immediate bidding for small state enterprises with cit- 
izen Stock Market Units (SMUs). 



Input: 

Serial file: Sorted Transaction Data Base (XDB), or a subset of it. 



Output Report: 

List of individuals attempting to transfer away a total of more than 1 SMU, the 
total attempted transfer amount, and optionally the entire transaction block for 
those individuals. 

Typical Usage: 

A local governmental entity applies module AUCTION to all transaction data 
in its possession after determining successful bidders at auctions of small state 
enterprises such as shops (especially including the transaction data reflecting 
those successful bids, see Appendix 4: Virtual Assets - Small State Enterprise 
Rights [SSER]). 

Since the assumption is that there will be an initial transferable allocation of 
1 SMU to each citisen, a warning is reported if attempted cumulative trans- 
fers exceed 1. Note that after the first investment cycle, if a portfolio owner 
had acquired additional SMUs, the warning may prove to be a false alarm. 
Conversely, if not all SMU-transfer-transaction data (such as from other suc- 
cessful small state enterprise auction bids) is available to the local government, 
AUCTION could foil to warn of a potential over-transfer (which could result in 
restitution to the government of the acquired asset plus profits). 



Module Logic: 

Invoke submodule XBLOCK to evaluate the transaction block, suppressing in- 
vocation of the Delegate* Order File (DORF) and forcing the inclusion of all 
price-contingent transfers away of SMUs. Trigger reporting if cumulative trans- 
fer away of SMUs exceeds 1. 
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DELCOMP (Delegate* Compensation) 



DELCOMP calculates the wMiwnmm thresholds of ddegatee compensation as a 
percentage of assets and earnings. 

Input: 

Serial file: Delegation Offer File (DOFF) 
Serial file: Transaction Data Base (XDB) 



Output: 

Random access file (updated): Ddegatee Order File (DORF) 
Typical Usage: 

DELCOMP is run after PASS2 has created the Delegation Offer File (DOFF). 
The delegatee compensation thresholds posted to the Ddegatee Order File 
(DORF) are subsequently used in PASS3 to establish final ddegations. 

Module Logic: 

The Delegation Offer File (DOFF) is sorted by ddegatee and by compensa- 
tion offer. The transaction block for each ddegatee is read into memory, along 
with the compensation offers from DOFF. Using the PERCENTAGE command 
specifications of the maximum amount of assets under discretion (as constrained 
by applicable law or regulation) and the percentage of assets to be sdected on 
the basis of compensation by earnings, determine maximum asset amounts by 
earnings and assets. For each of those two categories, step down the sorted com- 
pensation offers (starting at the highest), cumulating offered amounts, until the 
maximum amount or the minimum price (from the PERCENTAGE command 
again) is reached (see Appendix 3: DELEGATE, note 1). The compensation 
threshold is set to the compensation offer at that point. 
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DISPOSE 



DISPOSE prepares a Disposition Report (see Appendix 6) and appropriately 
excerpts from the Disposition File (DF) for transmittal to custodial financial 
institutions. 



Input: 

Serial file: Disposition File (DF) 

Serial file: Transaction Data Base (XDB) 



Report: Disposition Report 

Serial file: Disposition File: Excerpts (DFXXXX) 



Typical usage: 

DISPOSE is run after PASS5 has generated the Disposition File. The Dis- 
position File: Excerpts, along with a corresponding Disposition Reports (if 
appropriate), is then transmitted to each custodial financial institution. 



Module logic: 

DISPOSE first sorts the Disposition File by financial institution and sub-sorts by 
recipient ID. It then generates the Disposition File: Excerpt and any appropriate 
Disposition Report for each custodial institution after obtaining its ID record 
(containing address information) from XDB. 
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DORFGEN (DORF File Generator) 



DORFGEN generates the random access Ddegatee Order File (DORF) using 
information from the Transaction Data Base (XDB). 



Input: 

Serial file: Transaction Data Base (XDB) 



Output: 

Random access file: Ddegatee Order File (DORF) 



Module logic: 

Read the ddegatee-organiiation section of XDB, and post to random-access 
DORF non-proprietary transactions of types: ACQUIRE, CANCEL, FILTER, 
IDENT, PERCENTAGE, REINVEST and WHEN. 

Reserve room at the end of the posted transaction block for a PERCENTAGE 
record incorporating the final minimum compensation, to be posted by module 
DELCOMP. 



Generate access-keys based on ddegatee-organisation acronym for subsequent 
random access. 
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EGEN (Enterprise File Generation) 



EGEN generates and updates file the Enterprise File (EPRISE) with ID codes 
of all enterprises, distinguishing among SMU, SMU2 and UNSMU enterprises 
in the process. 

Input: 

Interactive date entry: Enterprise IDs and SMU category. 



Output: 

Random access file: Enterprise File (EPRISE) 



Module logic: 

Determine whether the EPRISE file exists yet. If not, prompt for the ID codes 
of all enterprises falling in the SMU, SMU2 (presumably none) and UNSMU 
categories respectively. Sort the enterprises by acronym and create EPRISE. 

If EPRISE already exists, upon request display current enterprises and allow 
deletion or addition of specific enterprises. 

Note: 

When SMU enterprises "spin off subsidiaries (e.g., to achieve demonopoliration 
goals), then the government agency maintaining the EPRISE file by means 
of module EGEN must insert the new spin-offs as SMU enterprises. If the 
restructuring is material to the original enterprise, any "surviving core" should 
also be treated as a new enterprise to avoid masking the discontinuity. 
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EVOTE (Enterprise Vote) 



EVOTE uses polling techniques to support enterprise shareholder votes in the 
context of extremely widespread share ownership. 

Input: 

For one or more enterprises: enterprise acronym, number of shares outstanding, 
threshold percentage ownership, requested number of names below threshold: 
N, output mode (mailing list or properly addressed copy of the decision to be 
voted on) and (if second output mode) text of decision to be voted on. 



Output: 

By enterprise, names and addresses of all Luge and N small shareholders and 
their percentage and number of shares, with a selection probability for small 
shareholders an increasing function of ownership percentage, either as mailing 
lists or mail-ready voting packets. 



Module Logic: 

Perform an initial scan on the Transaction Data Base (XDB) for large owners 
(i.e., above the threshold percentage) of the specified enterprises. Note that 
the set of tapes in the XDB series (which is sorted by ID code, including birth 
date for individuals) corresponding to citizens below a statutory minimum for 
voting in enterprise decisions can be omitted. For each ID code, invoke module 
XBLOCK to determine the quantities of each asset. For each enterprise in the 
input list, calculate the percentage ownership reflected in this transaction block. 
If it exceeds the threshold, "select" the ID code and cumulate its shares into 
"large shareholder total holdings." (In practice, depending on the threshold per- 
centages, the initial large shareholder scan may be restricted to the sorted XDB 
tapes containing transaction data for governmental entities and organisations.) 

Next, scan XDB for owners of percentages below the threshold. "Selection" in 
this case is made by a Monte Carlo technique, using a probability of: 



Selection probability = 1 — (1 — p) 5 ; 



TV V A Wkf * 
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vAere S is the number of shares in the portfolio, and p is the selection probability 
foi a single share as follows: 



m ; 

p ~ ($mall shareholder iotal holding*) 

vAere (small shareholder total holding.) equals (total shares outstanding) 
IuT(LU shareholder total holdings), H is the requested »»»^f^*^ 
Lite names, and /i(N) is an array of values determined by the Po»o» approx- 
imation to the binomial distribution as Mows: 

Jo *! 

This method of calculating selection probability ***** 
im yield approximately K small shareholder names (with a 50/50 probabihty 
of yielding either more or less). 

-Selection- results in either the addition of the name address and number 
and percentage of shares to a mailing list (partitioned into large and small 
shareholders), or else the automatic generation of a properly addressed set of 
all the voting decisions to be put to a particular individual or organisation. 

Notes: 

1 If a particular individual or organisation exceeds the threshold in at least 
one case, and is also -selected" as a small shareholder in another enterprise, two 
separately addressed mailings could be generated. 

2 The output option of sorted mailing Ests requires sufficient random access 
file space to retain all selected names and addresses. However, this capabihty 
can also include sorting by an address subfield (such as a sip code) or by the 
regional center initially registering the ID code (as a surrogate for the region of 
the current address) in order to expedite the mailing process. 

3 For this service, each enterprise might be charged a fixed fee, plus a per- 
name fee based upon whether the program generates a mailing list or the actual 
mail. The threshold percentage ownership and the number of names requested 
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would presumably be a function of the importance of the decision, perhaps with 
statutory miwimums. 

4. Since EVOTE deals only with share own«Mp recognised by the 

system, any shareholdings transmitted to financial institutions by TRANSFER 

transactions would have to be polled independently. 

5 Where a -selected" individual or organisation has validly delegated voting 
authority over at least some of its shares in the enterprise separate selection 
probabilities are calculated by appropriately allocating portfolio shares between 
the portfolio owner and each organisation to which it has delegated voting au- 
thority. 



PASS1 



PASS1 updates the Enterprise File (EPRISB) with information from current 
DIVIDEND transactions. PASS1 also estimates asset prices assuming all del- 
egation offers above ddegatee-spedficd minimum* are consummated. In the 
process, it creates an updated Transaction Data Base (XDB) file containing 
reinvestment transactions based on portfolio earnings. 



Input: 

Serial file: Transaction Data Base (XDB) 
Random access file: Delegate* Order File (DORF) 



Output: 

Random access file: EPRISE (updated with current dividends) 
Random access file: PRICES (updated with price estimate #1) 
Serial file: Transaction Data Base (XDB) (new copy) 
Serial file: ORDERS (also used as subsequent input) 



Module lope: 

First scan the segment of XDB containing enterprise transaction blocks to up- 
date EPRISE with information from DIVIDEND transactions, cumulating the 
dividends to totals for SMUs, SMU2s or UNSMUs as appropriate. 

Then process XDB (using module XBLOCK with the switch set to enable usage 
of file DORF), generate the ORDERS file for later use by PRICING, and create 
an update of XDB containing reinvestment transactions. These are formulated 
by cumulating portfolio earning* from equities (SMUs, SMU2s or enterprise 
holdings), government debt (i.e., not automatically posted to the Disposition 
File - DF) and foreign currency. 

The cumulated earnings are then allocated to assets (via ACQUIRE transactions 
at prevailing prices) in accordance with any applicable REINVEST transaction 
or default. 

PASS1 then invokes module PRICING which uses the ORDER file to generate 
price estimate # 1. Finally, PASS1 posts this estimate to file PRICES. 
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PASS2 

PASS2 estimates asset values using price estimate #1 to value delegation offers 
and lending offers. 

Input: 

Serial file: Transaction Data Base (XDB) 
Random access file: PRICES 

Output: 

Serial file: Delegation Offer File (DOFF) 
Module logic: 

Read a transaction block from XDB and call routine XBLOCK. Aggregate in 
memory offers to lend to potentially large borrowers, and upon completion gen- 
erate a lending report (see Appendix 6) for the borrowers 9 evaluation. 

After processing each transaction block, post delegation offers to file DOFF. 
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PASS3 



PASS3 generates price estimate #2 using the final delegations posted by module 
DELCOMP to the Delegation Older File (DORF). 



Input: 

Serial file: Transaction Date Base (XDB) 
Random access file: Delegatee Order File (DORF) 
Random access file: PRICES 



Output: 

Random access file: PRICES (update with price estimate #2) 
Serial file: ORDERS (also used as subsequent input) 



Module logic: 

Process XDB by invoking module XBLOCK and posting the returned array 
of orders to the ORDER file. Then invoke module PRICING which uses the 
ORDER file to generate price estimate #2. Finally, PASSS posts this estimate 
to file PRICES. 
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PASS4 

PASS4 uses price estimate #2 generated by PASS3 to decide whether to invoke 
ELSE transactions, and then calculates final asset prices. 



Input: 

Serial file: Transaction Data Base (XDB) 
Random access file: Delegatee Order File (DORF) 
Random access file: PRICES 

Output: 

Random access file: PRICES (updated with final prices) 
Module logic: 

Same as PASS3, except XBLOCK will return an order array which reflects price 
estimate #2 determining whether or not to invoke individual ELSE transactions. 



PASS5 



PASS5 uses the final asset prices generated by PASS4 to execute transactions, 
create an update Transaction Data Base (XDB) and generate the Disposition 
File (DF). 



Input: 

Serial file: Transaction Data Base (XDB) 
Random access file: Delegatee Order File (DORF) 
Random access file: PRICES 



Output: 

Serial file: Transaction Data Base (XDB) (new copy) 
Serial file: Disposition File (DF) 



Module logic: 

PASS5 uses the same logic as PASS3 and PASS4, except that it makes use of 
final asset prices. 

During processing of XDB, PASS5 also creates an updated version by: 

1. inserting the final interest rate (price) as the last subfield in each debt 
instrument (DXXXX, DIXXXX); 

2. inserting the final implicit interest rate (price), actuarial table # and periodic 
payment amounts (determined by invoking module ACTUARY) as the last three 
subfields in each annuity instrument (PAYOUT); 

3. suffixing to each potentially price-dependent transaction (i.e., ACQUIRE, 
ELSE and DELEGATE) another record documenting whether it was executed, 
either yes: *Y:in vestment cycle or no: "Xrinvestment cycle #::**; 

4. calculating actual delegatee compensation and transfering a portion of the 
delegated portfolio to the delegatee's account, either as a fixed percentage (if 
compensation was based on assets) or a percentage based on calculated total 
return (if compensation was based on "earnings"); and 

5. appending to each transaction block in the new XDB a summary record of 
the amounts of assets currently contained in the portfolio, along with a total 
valuation, as follows: 
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Zrasset l:amount 1: ... tasset n:amount nitotal valuation:: 

Finally, PASS5 generates the Disposition FUe (DF) by posting in the following 
format: 

Recipient ID code:name:address:phone:suppleinentary name: 
asset l:amount 1: ... :asset n:amonnt n:: 

information which module DISPOSE will process for transmittal to custodial 
financial institutions. 



PRICING 



PRICING creates o, updates file PRICES and updates file EPRISE. These files 
contain price estimates #1 and #2 and the final pnces for a»ets in a given 



investment cycle. 



Input: 

Random access file: PRICES 

Random access file: Enterprise File (EPRISE) 

Serial file: ORDERS 



Output: 

Random access file: PRICES 

Random access file: Enterprise File (EPRISE) 

Serial file: ORDERS (sorted version) 



Module logic: 

PRICING iterative^ calculates the -market^clearing" price for each asset which 
satisfies the largest quantity of bids and offers. In the ease of an asset with a 
S* offeror (of bidL) such a, PAYOUT, DXXXX and DDLXXX, that offeror 
(in these cases) establishes the price and the execution quantity is the amount 
of bids at or above that price. 

In the case of assets with multiple bidders and offerors, at the "market-clearing" 
price the amount of bids at or above it is equal to the amount of offers at or 
below it. PRICING finds this price by first calculating a complete cumula- 
tive offer-amount array (starting at the lowest offer and working upward), and 
then calculating the corresponding cumulative bid-amount array (starting at 
the highest bid and working downward) until the cumulative bid-amount equals 
or exceeds the cumulative offer-amount. 

In the case of transactions involving cross-prices, where a price-contingent bid 
uses the proceeds of a price-contingent offer, the bid amount will be a function 
of the market price obtained for the offered asset. 

In particular, if agent-i bids p i} for instrument-j, using the proceeds from offer- 
ing amount-*,* of instrument-k at price-p ifc , and if the market prices are cor- 
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rcspondingiy Pj and F*, this is equivalent to the following bid foi instrument-j: 

amount-j = qyu jlj-i 

and a corresponding offer for instrument-It: 

amount-k = qiju\ 

If at least one of the two price contingencies is an interest rate, then the cross- 
price constraint is broken out into its component constraints which must be 
independently satisfied: 

and Pk>Pik- 

If the bid-for instrument has no price contingency (i.e M the price in the corre- 
sponding ACQUIRE transaction equals 0), then set: 

Pij = MIN(default maximum price, Pj). 
If the offered instrument has no price contingency, then set: 

Pik = MAX(default minimum price, P k ). 

The default maximum and minimum prices are designed to be reasonable con- 
straints, and are set at a particular percentile along the spectrum of price- 
dependent bids and offers respectively. 



I t f 



Applying these principles to the assets in the Privatise!™ system, PRICING 
first reads the ORDERS file and sorts it by asset kind and price contingency. It 
then obtains the latest market price estimates from files PRICES and EPRISE. 
Estimates of prices for the single-offeror assets (DXXXX, DIXXXX and PAY- 
OUT) are calculated. Then prices are estimated for foreign currency assets 
(FCDM and FCUS) assuming cross-price contingencies and multiple bidders 
and offerors. 

At this point, the price of a SMU is calculated assuming cross-price contingen- 
cies and multiple bidders and offerors. In addition, arbitrage is automatically 
performed between SMDs and the component enterprise shares. When calcu- 
lating the cumulative offer-amount array for SMUs (starting at the lowest SMU 
offer and working upward), the lowest offers for enterprise shares which make 
up a SMU are aggregated if they represent a complete set, and treated as "syn- 
thetic" but legitimate SMU offers. The execution of synthetic offers increases 
the amount of actual SMUs by transforming a complete set of enterprise shares 
into SMUs. 

The cumulative bid-amount array for SMUs (starting at the highest SMU bid 
and working downward) is likewise augmented by synthetic SMU bids composed 
of the aggregation of the highest bids for enterprise shares which make up a 
SMU. In this case, a complete set of bids is unnecessary, and any unbid-for 
enterprise shares (or bid at less than a statutory minimum to prevent private 
parties from "vacuuming up" large quantities of shares at de minimis prices) in 
executed synthetic SMU bids are allocated to a government account. In effect, 
by operating the system, the government automatically reaps the rewards of 
arbitrage between SMUs and enterprise shares. 

After determining the price of a SMU, prices are calculated for shares in indi- 
vidual enterprises. This again proceeds on the assumption of cross-price con- 
tingencies and multiple Udders and offerors. However, the amount of shares 
allocated to executed synthetic SMU bids and offers are first subtracted from 
the cumulative bid-amount and offer-amount arrays respectively. 

After an iteration of estimating asset prices, the process is repeated so that bid- 
amounts which are a function of other asset prices can be approximated more 
closely. Therefore, using the new asset price estimates, updates estimates are 
prepared in turn for single-offeror assets (DXXXX, DIXXXX and PAYOUT), 
foreign currency (FCDM and FCUS), Stock Market Unit (SMU) and enterprise 
shares (EXXXX). Iterations continue until price estimates sufficiently converge. 
These prices are then posted to files EPRISE and PRICES. 
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Notes: 

1. Subsequent to the first investment cycle, non-PAYOUT debt in the gov- 
ernment (e.g., DLEVR, DUEVR) will be subject to the possibility of multiple 
offerors and be processed accordingly. This will necessitate adjustments to the 
face value of debt being liquidated, to take into account changes in net present 
value due to changes in price (i.e., interest rate). 

2. When appropriate, PRICING will use the SMU pricing technique to calculate 
the price of a SMU2, an UNSMU or industry-specific "sub-baskets* which hier- 
archically comprise any of those three stock "baskets.'" Note that hierarchical 
"sub-baskets" could not only promote efficient capital formation by presenting 
investment vehicles for emerging industries, but they would also provide the 
opportunity for additional government arbitrage income. 

3. When investors become more experienced, it may be useful to offer the 
ability to bid or offer at prices equal to an investor-specified percentile along 
the spectrum of price-dependent bids or offers. 
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XACT 



XACT generates the Transaction Data Base (XDB). 
Input: 

Transaction records from serial device(s). 
Output: 

Maximally sorted transaction records to a serial device. 
Module Logic: 

This module accepts transaction records (from any available device, e,g- ter- 
minal, diskette or tape), optionally performing a preliminary validity check. 
Transaction blocks containing records in error ate either directed to an alter- 
nate output device for subsequent review and correcting, or else to a terminal 
operator. The terminal operator could either correct a terminal-entered fecord, 
or iiyect appropriate CANCEL, substitute and NOTE records In the case of an 
erroneous record entered from another device (in the interest of preserving a 
complete audit trail). 

The transaction records are then posted to an array of transaction blocks in main 
memory. This array is sorted (by ID code) when full or upon completion, and 
transferred to a disk file if available. This process is iterated until completion 
or until no more disk space is available. Then the disk files (if available) are 
merge-sorted to a serial output device writing to media such as diskettes (each 
holding about 1 megabyte of data) or 8mm tapes (each holding up to 5 gigabytes 
[sic] of data). 

XACT processes all possible transactions from all recognized entities. The in- 
termediate product is a set of diskettes or tapes, sorted at an intermediate level 
(i.e M chunks corresponding to the amount of main memory or disk memory 
available, whichever was greater, will be sorted "intra-chunk", but without any 
"inter-chunk" sorting). 

In practice, data entry will likely be compartmentalised in the initial stages into 
what can be considered "logical sub-files", e.g.: 



i 
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1) Citizen Data Base (CDB), comprising transaction records for individual cit- 
izens. This can range from simply the entry of an ID record (which could be 
coordinated with voter registration or adapted from other governmental data 
bases, and would correspond to an initial census), to a comprehensive set of 
transactions to buy or sell different assets or authorize delegation of investment 
authority. 

2) Auction Data Base (ADB), comprising the exchanges of SMUs for SSERs (see 
Appendix 4: Virtual Assets: Small State Enterprise Rights). These transactions 
would typically result from successful bids at local auctions. The governmental 
entity arranging the auction, which would presumably obtain a percentage of 
successful bids, would use module AUCTION to try to ensure that individuals do 
not transfer more than their allotment (i.e., one) of SMUs (subject to restitution 
of anySSERs). 

3) Testamentary Data Base (TDB), comprising transactions to dispose of the 
portfolio of a deceased individual. These would typically be generated by appro- 
priate local authorities after processing any will or conducting any "probate. 

4) Enterprise Data Base (EDB), Financial Institution Data Base (FIDB), ^Char- 
itable Institution Data Base (CHIDB), Foreign Investor Data Base (FORNDB), 
Government Data Base (GDB), Privatisation Board Data Base (PBDB) would 
each likewise comprise transactions submitted by the respective entities. 

However, it should be emphasised that these "logieal sub-files" are actually just 
parts of a single Transaction Data Base (XDB), and any "logical distinctions" 
are transparent to the Privatise!'" software system. Indeed, in its final mode, 
XACT reads input from multiple devices (such as 8mm tape drives), repeats the 
transaction validity check, performs an ID code merge-sort irrespective of the 
logical sub-file" source, and outputs to another device (such as an 8mm tape 
drive again). By appropriately iterating this process, an incompletely sorted 
Transaction Date Base (XDB) of even very great size can be sorted completely 
and effectively. 

Notes: 

1. A subsequent version (MXACT: Multi-user XACT) will allow multiple users 
on a single computer to simultaneously input transaction records, again to be 
sorted in main memory and posted to a user-specific disk file. When the first 
user-specific disk file is filled, a flag will signal all program copies to dose out 
their current disk files and open alternates to continue processing. This will 
trigger another program copy to merge-sort the closed disk files to the serial 
output device. However, this module will likely not be portable between oper- 
ating systems or even computer lines. 
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2. XACT automatically checks for and when necessary generates appropriate 
transactions to initially transfer SMUs or SMU2s to citizens. 
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XBLOCK 



XBLOCK analyses a tiaasaction block (Le. t all the transactions for a particular 
ID code) in the Transaction Data Base (XDB). 



Input: 

Parameters: transaction data block for an ID code, and a switch which specifies 
whether to invoke the Delegate Order File (DORF). 
Global data: Asset prices by investment cycle. 
Random access file: Delegatee Order File (DORF). 



Return: 

1. Number of kinds of assets ever in the portfolio, total portfolio valuation. 

2. An asset array containing: asset kind, cumulative transfers, current asset 
quantity, asset price, asset value. The array is sorted by last date the asset was 
contained in the portfolio, and subsorted by asset value. 

3. An array of orders to input to module PRICING: (assetl,pricel,asset2 > price2,amount2) 



Processing Logistics: 

Called internally by software modules as necessary (e.g., AUCTION, PASS 1-5). 
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Included Module - GLOPARM (Global Parameters) 



Policy choices 

compmna: compensation minimum as % of assets, 
compmne: compensation minimum as % of earnings* 
compmxa: compensation maximum as % of assets, 
compmxe: compensation maximum as % of earnings, 
maxfilt: maximum number of simultaneously operative filters. 



Technical specifications 

bdlim: block delimiter u newline character". 

decpt: decimal point V\ 

fdlim: field delimiter 

nfield: null field "na". 

numfmt: number formatter *,"• 

rdlim: record delimiter 
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Appendix 3: Transaction Commands (with allowed abbreviations) 
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TRANSFER (XFER T) 
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WHEN (W) 



ACQUIRE (ACQ A) 



Syntax: 

ACQ:date entered:as of date:assetl:pricel:asset2:price2:axnount2:: 

ACQUIRE attempts to obtain assetl at pricel or better by selling amount2 of 
asset2 at price2 or better. These constraints are relaxed to a single cross-rate 
constraint (unless an interest rate instrument such as DXXXX or PAYOUT is 
involved) as follows: 

Bid for assetl at a cross-price of pricel/price2 in an amount equal to 



amount2 * (market-price2/market-pricel) 

along with a corresponding offer for asset2 at a cross-price of price2/pricel. 
See Appendix 4 for asset categories. 

Specifying a price of 0 for either assetl or asset2 suppreses that price criterion. 
In that case, the bid or offer is no longer a cross rate, and is executed if the 
non-zero price is satisfied. If both prices are 0, then amount2 of asset2 is sold 
at whatever xnatket-price2 is determined to be, and those proceeds are used to 
purchase assetl at whatever market-pricel is determined to be. 

Examples: 

ACQ: , :931231:ESTM:10:SMU:26000:.5:: 

[The apostrophe indicates the previous entry date is used. The transaction is 
to take place "as of December 31, 1993. Shares in the enterprise STLI are 
to be bought at a price of no more than 10 (local currency) per share, using 
the proceeds from the sale of .5 SMUs at a price of no less than 25000 (local 
currency) per SMU. The prices need not be satisfied independently, but are 
considered to be a cross-rate.] 

ACQ:':93:DLEVR;01:8%5MU:0:25%:: 

[The previous entry date is used, and the transaction is to take place "as of" 
1993 on the default (for the ACQ transaction) date of December 31. Debt of 
LEVR to mature in the year 2001 is to be bought at an interest rate of no less 
than 8% (the % sign is optional here), in exchange for 25% of the SMUs in the 
portfolio (here the % sign is necessary to distinguish from an absolute amount 
of SMUs) to be sold at whatever the market price is determined to be.] 
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ACQi^^PAYOUTjFNBXjQ^TOl^SlOOljSsM^roiSMUilOOOO^Oro:: 
[An annuity to be paid by financial institution FNBX extending from July 1, 
1994 to October 1, 1998, with a light of survivorship and monthly payments, 
is to be purchased if the implicit interest rate is at least 4% (on the bans of a 
standardized actuarial table), with the proceeds from the sales of 20% of the 
SMUs in the portfolio at a price of at least 10000.] 

ACQ:V:FCDM:76:SMU:0:5%:: 

(Acquire deutsche marks at 75 (local currency) per DM or better using proceeds 
from selling 5% of SMUs in the portfolio. The deutsche marks are to be kept in 
an interest bearing account (with short term maturity less than 1 year). 

Notes: 

1. An ACQUIRE transaction is only valid for one investment cycle. For exam- 
ple, for a calendar-year annual investment cycle, any ACQUIRE with an "as oP 
date in 1992 and entered by the cut-off date would be a candidate for executing 
during processing in early 1993, after which it would expire. However, if the "as 
oP date were in 1993, it would be skipped over until the next processing cycle. 

2. If an enterprise offers shares of itself in excess of its "treasury shares*, that 
is equivalent to a stock subscription (and presumably subject to regulatory 
oversight). 

3. Certain assets cannot be used in the place of "a3set2" to ACQUIRE other as- 
sets by any entity other than the issuer. For example, debt (DXXXX, DIXXXX 
and PAYOUT) is transmitted to custodial financial institutions via the Disposi- 
tion File (DF). (Early liquidation of such debt instruments will likely entail nego- 
tiations with or through the custodial financial institution.) Even government- 
backed annuities (PAYOUT) are invalid as tt asset2" (to prevent processing and 
asset-debasement difficulties). Therefore, the only debt-based instrument eli- 
gible to be used as "asset2" by an entity other than the issuer is debt of the 
government (e.g., DLEVR). Even this will not be supported in the first invest- 
ment cycle, since there will be no such loans on the system initially. When it is 
allowed for entities other than the government to offer their holdings of its debt 
(which will aid in interest rate price discovery), adjustments to the lace value of 
debt being liquidated will be made to take into account changes in net present 
value due to changes in price (i.e., interest rate). 

4. Note that the government can enter ACQUIRE transactions, presumably 
with suitable public notice, to auction off bundles of SMUs or shares in specific 
enterprises at or above a fixed asking price. 
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BANK (B) 

Syntax: 7 
BANK:date entered:as of dateiacronym:: 

BANK is entered by an enterprise to specify the financial institution which will 
process its debt payments. 

Example: 

ID:930415:931231:421145000SIEXYSTLI:: 
BANK:V:FNBR:: 

[Enterprise STLI specifies financial institution FNBR as its debt processing 
agent, as substantiated by any required off-line agreements and oversight ap- 
provals.] 

ACQ:V:DFNBR;D:0:DSTLI;99:8%:100,000:: 

(STLI offers to borrow 100,000 (local currency) at 8% or less, to be repaid in 
1999. In this case, any proceeds are to be held as a demand deposit with FNBR 
at prevailing rates.] 

ID:930630:931231:19601120JSMXYJKLM:: 
ACQ:V:DSTLI;99:8%:DLEVR;D:0:$0,000:: 

[Individual JS offers to liquidate 50,000 (local currency) of his demand loan to 
LEVR, and use those proceeds to lend to STLI at 8% or more, with the principal 
to be repaid in 1999.] 

In this example, the loan would be consummated in an amount of 60,000 (local 
currency). Module PASS5 posts the resulting asset (in the form of a loan) of 
individual JS to the Disposition File (DF). Module DISPOSE includes a record 
for this asset in the Disposition File: Excerpt sent to financial institution FNBR 
(DFFNBR). Each year, STLI must then pay 4,000 (local currency) to FNBR 
for distribution to JS. 



CANCEL (CXL C) 
Syntax: 

CXL:date entered:as of date:asset-specific ACQUIRE, PREVious 01 ALL trans- 
action^):: 

This command provides the ability to cancel previous transaction(s) which have 
not yet been executed. 

Examples: 

CXL:931015:931015:ALL:: 

[Cancel all previously entered (but as yet unexecuted) transactions for this ID.] 

CXL:V:SMU:: 

[Cancel previous transactions to acquire SMUs.) 
CXL:940125:940125:PREV:: 

[Cancel previous transaction. This might be inserted during processing and a 
substitute transaction entered, if an error is detected.] 

Notes: 

1. Subsequent transactions with a "date entered" later than the CANCEL "as 
oP date are not canceled. 

2. Transactions which were entered before the CANCEL "as of" date are not 
canceled if they were executed (i.e., an asset was already exchanged for another). 



DELEGATE (DLG D) 



Syntax: 

DLG:date entered:as of date:delegated authority (Invest, Vote): 
asset(s):amount:delegatee-acronym:compensation(as % of Assets or Earnings):: 

This transaction delegates either investment or voting authority over specified 
assets to the identified ddegatee-organization. 

Examples: 

DLG: , :'d:SMU:20%JNVI:10%E:: 

[Investment authority over 20% of the SMUs in the portfolio is offered to the 
delegate* organisation IN VI (which must be approved and registered) at a com- 
pensation of 10% of the subsequent earnings, taken to mean total return, includ- 
ing interest, dividends and stock appreciation (which will reflect the delegatee'* 
investment decisions).] 

DLG:V:I:SMU:10%:INVI:1%A:: 

[Investment authority over 10% of the SMUs in the portfolio is offered to dele- 
gatee organization INVI, at an annual compensation of 1% of the Assets, to be 
transferred without liquidation. Therefore, if the offer to delegate is consum- 
mated, and if there had been 1 SMU in the account, then .001 SMU (1% of 10% 
of 1) would be transferred from the portfolio to the delegatee organization.] 

Notes: 

1. Each delegatee organization must be approved and registered, with a max- 
imum amount of assets under its discretion set at the lowest of: a statutory 
maximum, a limit set upon registration (based upon the organization's finan- 
cial resources and perhaps the experience of its personnel), and a lower limit 
of its own choosing. Perhaps delegatee organizations should be forbidden from 
purchasing for their own account assets vulnerable to manipulation, such as 
stock in individual enterprises. Offers to delegate are ranked in order of com- 
pensation in two lists (one for compensation as a percentage of assets, the other 
for compensation as a percentage of earnings). 

The delegatee-organization has the option to establish minimum percentage 
compensation (by assets and earnings) which it will accept, and must specify 
in advance what percentage of the assets under its discretion is to be selected 
on the basis of asset-related compensation versus earnings-related compensation 
(see the PERCENTAGE command). For example, a delegatee organization with 
an aggressive investment philosophy might specify that only 10% of the assets 
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under its discretion is to be selected from the highest compensation offers as a 
percentage of assets, while 90% is to be selected from the highest compensation 
offers as a percentage of earnings. 

The actual compensation for all delegations is set at the lowest accepted offer 
(in the appropriate category), except that the lowest offers axe truncated if they 
would reduce delegatee remuneration (i*e. f if lowering the actual compensation 
rate would more than offset the increase in total amount). If the offered price 
P is expressed as a function of cumulative amount Q (starting from the highest 
offers), this is equivalent to solving for Q-accepted by: 

maximising: P(Q) x Q; 
subject to: Q-accepted < Q-maximum-authorised; 
and: P(Q-accepted) > P(minimum-acceptable); 

and setting the price for all accepted delegations equal to P(Q-accepted). The 
list of registered delegatee organisations, a description of their personnel and 
expected investment approach, the percentage of assets to be accepted on the 
basis of assets versus earnings, and the maximum amount to be accepted should 
be regularly published. 

2. Statutory constraints such as the prohibition of the sale of stock voting au- 
thority (especially over individual enterprises), as is the case in Western systems 
such as the United States to prevent abuse, can easily be implemented by set- 
ting the maximum compensation offer at zero. The result would in effect be a 
continuing and comprehensive "proxy" delegation. 

3. If an individual acquires authority to enter transactions for the portfolio of 
another individual (such as an adult child being asked by an elderly parent to 
manage a portfolio), the responsibility for authentication rests with the same 
agency authenticating transactions entered by the actual portfolio owner. In 
other words, "delegation" (voluntary or otherwise) to an individual is transpar- 
ent to Privatize™, and is authenticated by the "personnel" and/or "paper- 
work" system. 

4. DELEGATION transactions entered by delegatee-organizations themselves 
are not allowed (except for their proprietary assets, when it might even be 
required). In other words, redelegation is not allowed. This is to prevent nearly 
intractable processing difficulties, in addition to avoiding the potential for an 
inappropriate convergence of investment strategies. 
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DIVIDEND (D1V D) 
Syntax: 

DIVIDEND:date enteted:as of <iate:total dividend payment:: 

DIVIDEND is entered by an enterprise, and specifies the total dividends which 
it has paid over to be allocated to shares contained m the PnvaW"' system. 
Module PASS1 uses this information in the process of calculating total portfolio 
earnings for reinvestment. 

Examples: 

DIVIDEND:V100,000:: • 

(This enterprise has paid over 100,000 (local eurreney) to be proportionately 

allocated as dividends to all its shares on the PrivatueF" system.] 

ACQ:V:VAL:S:DLEVR;D:S:100,000:: 
DIVIDEND:V:100,000:: 

[This enterprise has extinguished 100,000 (local currency) worth of debt » 
LEVR for value received. That value received is the credit of 100,000 (local 
currency) to be distributed as dividends.] 

Notes: 

1. DIVIDEND is only valid in the transaction block of an enterprise. 

2. An appropriate government agency (such as the Priva^^Board) must 
authenticate the transfer of sufficient resources to fund a DIVIDEND transac- 
tion. 

3 This transaction can also be used to distribute payments to shareholders as 
a result of a successful tender offer to take an enterprise private (see discussion 
in Appendix 1 - EPRISE, note 2). 
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ELSE (E) 
Syntax: 

ELSE:ACQ:date entered:as of date:assetl:pricel:asset2:price2:amount2:: 

ELSE is designed to provide the option to execute an alternative ACQUIRE 
transaction if a primary DELEGATE or ACQUIRE transaction (ails to be exe- 
cuted. This is intended to somewhat compensate for the significant interval in 
the investment cycle. 

Examples: 

DLG:V:I:SMU:20%JNVI:10%E:: 
ELSE::ACQ:V:DLEVR;D:0:SMU:0:20%:: 

[Offer to delegate investment authority over 20% of the portfolio SMUs to del- 
egate* INVI in return for 10% of earnings. However, if the offer is not con- 
summated, exchange those SMUs for a demand loan to LEVR at prevailing 
prices.] 

ACQ:V:DLEVR;D:10%:SMU:25000:20%:: 
ELSE:ACQ:V:FCDM:75:SMU:15000:20%:: 

[Attempt to sell 20% of the portfolio SMUs at a price of at least 25000, and use 
the proceeds to purchase a demand loan to LEVR at an interest rate of at least 
10%. However, if either price can't be obtained, then attempt to sell 20% of the 
portfolio SMUs at a price of 15000 or better, and use the proceeds to purchase 
deutsche marks for 75 or better (taking the prices to mean a cross-rate).] 

Notes: 

1. ELSE can only follow a DELEGATE or ACQUIRE transaction. 

2. The body of an ELSE can only be an ACQUIRE transaction. 

3. If the ELSE follows an ACQUIRE, the asset pairs cannot be the same, in 
order to avoid wasteful processing overhead. For example, in the second example 
above, the prices of 25000 and 10% could not merely be relaxed to 20000 and 
8% respectively in the subsequent ELSE transaction. For the purpose of this 
comparison, all debt of any particular entity is considered to be the "same* 
asset irrespective of maturity. 
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FILTER (FLT F) 
Syntax: 

FILTER:date entered:as of daterlabd: 

account type:ID-acronym:birthdate interval:sex:asset(s):amount interval:: 
or 

FILTER:date entered:as of datedabek: 

Filter is a transaction entered only by a delegatee organization (or the govern- 
ment itself) so that subsequent transactions only apply to selected portfolios or 
assets* Account type is a single letter (C,F 9 M,N,E,D or G) as follows: Citizen, 
Foreign investor, financial institution (Money), charitable institution (Need), 
Enterprise, Delegatee or Government. Delegatee transactions not preceded by 
a FILTER command apply to all assets under its discretion, both its own pro- 
prietary assets and those for which investment authority has been delegated 
to it. In practice, a ddegatee-organization should initiate its transaction block 
with a pair of FILTER statements keyed to its own acronym, bracketing the 
transactions applicable to its proprietary account. 

Examples: 

FILTER:V:proprietary account:D:INVI:: 
FILTER:':':proprietary account:: 

[The transactions bracketed by the two FILTER transactions labelled "propri- 
etary account" apply only to assets owned by the delegatee-organization INVI 
itself.] 

FILTER: 1 :':boomers:C:na:19501001;19601231:X:SMU:.5;2.5:: 
FILTER:V:boomers:: 

[The transactions bracketed by the two FILTER transactions labelled "boomers" 
apply only to delegations by Citizens born between October 1, 1950 and De- 
cember 31, I960, whose account (including the non-delegated portion) contains 
between .5 and 2.5 SMUs.] 

FILTEILheavy metal:E:STLI:: 

FILTER:heavy metal:: 

[The transactions bracketed by the two FILTER transactions labelled "heavy 
metal" apply only to delegations by Enterprise STLL] 

Notes: 
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1. Multiple filters (up to a maximum number equal to MAXFILT) can be 
simultaneously operative for a given delegatee, either nested or intersecting. 

2. Inapplicable trailing fields can be omitted, as in the example labeled "heavy 
metal." 

3 Matching FILTER transactions, and the transactions which they bracket, 
are considered a sub-block and kept intact throughout the merge-sorting of the 
Transaction Data Base (XDB). 

4. FILTER sub-blocks entered by the government itself are always executed 
even if not "invoked" by the destination portfolio. For example, the government 
could initially allocate .5 SMUs to the "social security" account of all dtieens 
born on or before January 1, 1928 with the following transactions: 

FILTER:V:pensioners:C:na:18700101;19280101ma:na:na:: 

SECURITY:':':: 
ACQ:V:SMU:S:LSER4S:.o:: 
SECURITY:':':: 
FILTER:': 1 :pensioners:: 



GRADE (G) 
Syntax: 

GRADE:dateentered:as of date:evaluator acronym 

GRADE allows an authorised evaluator organisation to enter its evaluation of 
another organisation which is capable of standing behind debt or an annuity. 
The evaluation is entered on a scale of 0 to 100, with a standardized interpreta- 
tion of various scores to be promulgated by the government agency capable of 
authorising organisations to enter such evaluations. This grading information 
is used to inform the public. Collective grading information can also be used 
to aggregate bids and offers of comparable organisations in the process of esti- 
mating market-clearing interest rates and generating a lending report to update 
borrowing transactions. 

Example: 

GRADE:V:SNP:MLPF:90:: 

[Authorised evaluator organisation SNP grades the financial stability and cred- 
itworthiness of organisation MLPF at 90.] 
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IDBNT (ID I) 
Syntax: 

ID:date entered:as of date:ID code:name:address:phone:suppleroentary name:: 

ID identifies the entity which owns and controls a portfolio (either a Citisen, 
Foreign investor, Enterprise, financial institntion [Money], charitable institution 
iNeedl, Delegate* organisation, or Government). It remains operative for sub- 
sequent transactions until another ID transaction is entered. The contiguous 
set of transactions associated with a particular ID is termed a "block." 

Examples: 

JJ):930215:930101:19601120JSMXYJKLM:John Smith: 

100 Main Street; Anywhere:555-1212(h);555-1213(w):Jones:: 

[Field 4: This is a citisen (the first digit in the ID code is a 1 or 2) born November 

20 1960, with initials JS, Male, with TD first issued by regional center XY, and 

distinguishing personal code of JKLM. Field 5: name. Field 6: address. Field 

7: telephoned) (if any). Field 8: mother's maiden name.] 

m:930215:930101:34567890rUAXYQRST:mvestorsUrdimited: 
100 GeldstrassejZurieh, Switserland:01/012/855-llll:Manfreq Q. Contact:: 
[Field 4: Foreign investor (first digit is a 3, while the following digits can be 
used to code individuals versus organisations), initials IU, Alien, ID first issued 
by processing center XY, distinguishing code QRST. Fields 5-7: name, address, 
telephone(s). Field 8: contact person.] 

ID:930215:930101:421145000SIEXYSTLI:SteelInc.: 
1 Steel Inc. PlasajSteel City:555-5555:Steely Dan Executive:: 
[Field 4: Enterprise (first digit a 4), industrial code = 21, enterprise # = 45000 
(independent of industrial code), initials SI, Enterprise, ID first issued by pro- 
cess center XY, enterprise acronym STLI (should be unique and correspond to 
enterprise #). Fields 6-7: name, address, telephone^). Field 8: contact person 
(presumably CEO).] 

ID:930215:930101:51100100FNMXYFNBR:First National Bank of Rocket City: 
1 First National Bank Plaxa;Roeket City:555-6666:Rock E. Fella:: 
[Field 4: Financial institution (first digit a 5), with financial institution code 
(e.g., bank, insurance company, pension fund, brokerage house, evaluator-organizati 
of 11, financial institution # = 100 (independent of financial institution code), 
initials FN, Money, ID first issued by processing center XY, financial institution 
acronym FNBR.] 
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ID:930215:930101:60100001CVNXYSOSV:Friends of SOS Childrens* Villages 
International:1170 Broadway;NY;10006:: 

[Field 4: charitable institution (first digit a 6), with charitable institution code of 
01 t charitable institution # = 001 (independent of charitable institution code), 
initials CV f Need, ID first issued by processing center XY, charitable institution 
acronym SOSV.] 

ID:930215:930101:79900150DUDXYDECU:Decisions Unlimited: 
711 Analysis Plasa;Rocket Science Gtty:777-7777:Lucky Eddie, Ph.D.:: 
[Field 4: Ddegatee organisation (first digit a 7), organization code = 99, delega- 
te* organization # = 150, initials DU, Ddegatee, ID first issued by processing 
center XY, (unique) acronym DECU. Fields 2-4: name, address, tdephone(s). 
Fidd 5: contact person.] 

ID:930215:930101:90300000LRGXYLEVR:Leviathan Republic: 
1 Memorial Drive;Capital City:lll-llll John Q. Appointee, MoF:: 
[Fidd 4: Government (first digit a 9), nation-state # = 03, regional govern- 
ment # = 00 (i.e. t not applicable^a"), local government # = 000 (i.e., *not 
applicable-" na") (note that transactions for a local government would have ap- 
propriate index numbers for both regional and local government), initials LR, 
Government, ID first issued by processing center XY, (unique) acronym LEVEL] 

Note: 

For some purposes (e.g., when an enterprise specifies its employees, and dti- 
sen records are automatically generated for incorporation into each employee's 
individual transaction block) the fidds after the ID code can be omitted. 
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JOIN (JN J) 
Syntax: 

JOIN:date eniered:as of date:enterprise acronym: 
capacity (Ceo, Board, Officer, Employee [non-officer]): 

stock compensation (denominated in local currency, # of shares, or % of out- 
standing shares):: 

This transaction indicates that an individual joined an enterprise as of the spec- 
ified date, in the indicated capacity. This record is originally entered by the en- 
terprise, which submits a series of such JOIN records, but with the "enterprise 
acronym" field replaced by an "individual code" field. These enterprise JOIN 
transactions are then used to generate individual JOIN transactions. This gen- 
eration will take place late in the processing cycle, after all enterprise data has 
been centralized, to inhibit intentional or unintentional errors. (For example, 
instances where an individual is reported to be affiliated with multiple enter- 
prises are reported. This will also help in the review of Privatisation Business 
Plans to flag potential overlap of enterprises.) 

Examples: 

ID:930215:930101:421145000SIEXYSTLLSteel Inc.:: 
JOIN:V:19431120JRMXYABCD:C:.01%:: 
JOIN:V:19500125PJMXYZYXW:O:100S:: 
JOIN:*:930701:19501205MSMXYFGHI:E:500:: 

[This sequence of transactions is entered by enterprise STLI, and results in the 
following individual JOIN transactions bong generated.] 

ID:930215:930101:1943112WRMXYABCD:: 
JOIN:V:STLI:C:.01%:: 

[As of January 1, 1993, this individual joined enterprise STLI as its CEO, with 
annual stock compensation equal to .01% of outstanding shares.] 

ID:930215:930101:19500125PJMXYZYXW:: 
JOIN:V:STLI:O:100S:: 

[This individual joined as an Officer, with annual stock compensation equal to 
100 shares.] 

ID:930215:930701:19501205MSMXYFGHI:: 
JOIN:V:STLI:E:500:: 

[MS joined STLI as an employee (non-officer) halfway through the year, with 
stock compensation of 500 (local currency) per annum. Therefore, 250 units of 
local currency will be used to purchase shares of STLI for his account.] 
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LEAVE (LV L) 
Syntax: 

LEAVE:date entered:as of date:enterprise acronym:: 

This transaction specifies that an individual has left an enterprise on the given 
date. Therefore, stock compensation is terminated as of that date. Like the 
JOIN transaction, individual LEAVE transactions are generated from LEAVE 
transactions submitted by the enterprise. 

Example: 

LEAVE:930901:930815:STLI:: 

[This individual left enterprise STL1 on August 15, 1993, up to which point any 
applicable stock compensation will be prorated.] 
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NOTE (N) 
Syntax: 

NOTE:datc entered:as of datemon-executing commentary:: 
NOTE provides the ability to introduce commentary. 
Example: 

NOTE:V:Previous record was cancelled due to apparently incorrect data in the 
last field. Ms. Q. X. Data-checker.:: 



16 8 



OVERSIGHT (OVER O) 
Syntax: 

OVERrdate entered:as of date:enterprise acronym: 

privatisation date:demonopolisation datc:confiscation percentage:: 

Only the Privatisation Board (or other authorised government agency) can sub- 
mit this transaction, which establishes the privatisation and demonopolisation 
dates of an enterprise. Achievement of privatisation is a prerequisite for ac- 
crual of compensation stock in privatised large state enterprises. Achievement 
of demonopolization is a prerequisite for recipients of such compensation stock 
(whether as a member of the board, officer, or non-officer employee) to transfer 
(away) any stock in that enterprise (even if some of it had been purchased, and 
even if the individual has already left the enterprise). 

The "confiscation percentage' 1 is equal to the Privatisation Board's estimate of 
the percentage of share value at demonopolisation attributable to monopoly rent 
arising subsequent to privatisation. The "confiscation percentage" of compensa- 
tion stock earned previous to certification of demonopolisation is automatically 
transferred to the governments social welfare account. However, if certification 
of demonopolization is achieved (on an "as of basis) within a safe harbor in- 
terval (e.g., 1 to 2 years), then the "confiscation percentage" must be set to 
0. 

The net result is to strongly encourage those individuals entitled to compensa- 
tion stock in an enterprise to achieve its demonopolisation as rapidly as possible. 

Examples: 

OVER:930315:930316^TLI:930601:: 

[The Privatisation Board approved the Privatisation Business Plan of enterprise 
STLI, and set the effective date of privatisation to be June 1, 1993, perhaps to 
coincide with an entire cohort of enterprises being privatised. Note the absence 
of the inapplicable trailing fields.] 

OVER:940601:940601:STLI:930601:940515:: 

[The Privatization Board certifies the demonopolisation of STLI on May 15, 
1994.] 

Notes: 

1. This transaction applies only to privatised large state enterprises. Authen- 
tication of other enterprises allowed onto the Privatise!™ system is the re- 
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sponsibility of the agency with authority over operation of module EGEN which 
generates the Enterprise File (EPRISE) (see Appendices 1 and 2). 

2 It remains possible for key executives to purchase, before demonopolisa- 
tion is achieved, stock in their enterprise at prices which do not sufficiently 
anticipate subsequent monopoly rent. Therefore, any request for certification 
of demonopolisation submitted after the safe harbor interval should include the 
transaction blocks of members of the board and officers of an enterprise. The 
Demonopolisation Board could then condition certification of demonopohsation 
upon confiscation of any appropriate percentage of even non-compensation (i.e., 
purchased) stock in the enterprise. This authority would presumably only be 
invoked in cases of significant abuse. 
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PERCENTAGE (PER P) 
Syntax: 

PERcVanininraxn compensation (% of assets):minimum compensation (% of 
earnings): maximum amount of assets under discretion:% of assets selected 
on the basis of compensation by earnings:: 

PERCENTAGE enables a delegatee-organisation to specify its minimum ac- 
ceptable compensation, the mmrimnin amount of assets under its discretion and 
the percentage to be selected on the basis of compensation by earnings (with 
the rest selected on the basis of compensation by assets). 

Examples: 

PER:V:.5:5:250,000,000:77:: 

[This delegatee-organisation requires that its compensation be at least .5% of 
assets or 5% of earnings; it will not accept discretion over total assets exceeding 
250,000,000 (in local currency); and it chooses to have 77% of the delegated 
assets under its discretion selected on the basis of earnings.] 

Notes: 

1. Statutory and decretal constraints remain, such as maximum compensation 
percentages and maximum amount of delegated assets subject to discretion by 
any single delegatee-organisation. 

2. Regulatory constraints also remain, such as any stricter limit on the maxi- 
mum amount of delegated assets on this particular delegatee-organisation im- 
posed by its oversight agency. 

3. There is no guarantee that there will be any offers to delegate which exceed 
the minimum compensation percentages. On the other hand, the maximum 
amount of assets may be reached with all offers higher than those minima. 

4. Default values are established by law or decree, and are contained in IN- 
CLUDED MODULE - GLOPARMS (see Appendix 2). 

5: The PERCENTAGE record which DELCOMP posts at the end of the Delega- 
tee Order File (DORF) does not update the Transaction Data Base (XDB), and 
so is unambiguously attributable to DELCOMP (rather than to the delegatee 
itself) by its context. 
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REINVEST (RNV R) 
Syntax: 

RNV:date enteredras of date:assetl:%:asset2:%:...:assetn:%:: 
REINVEST specifies how the earnings of a portfolio are to be invested. 
Example: 

RNV:930215:931231:ESTLI:50%:SMU:20%: 

DLEVR;96:5%:DLEVR;97:5%:DLEVR;98:5%:FCUS:15%:: * 
[Invest 50% of portfolio earnings in enterprise STLI, 20% in SMUs, 5% in debt 
to LEVR maturing in each of 1996, 1997 and 1998, and 15% in U.S. dollars.] 

Note: 

Dates are used only to determine the most recent, and therefore controlling, 
REINVEST transactions. 
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SECURITY (SBC S) 
Syntax: 

SECURITY:date entered:as of date: 

SECURITY transactions are entered in pairs. The transactions which they 
bracket apply to the "social security* portion of a portfolio, for which valid 
assets are limited to Stock Market Units (SMUs), government debt (DXXXX or 
DKXXX specifying a governmental entity) or lifetime annuities (PAYOUT). 

Examples: 

SECURITY:921115:930101:: 
ACQ:V:SMU:S:LSER:S:.25:: 
SECURITY: 1 : 1 :: 

[This "initialisation transaction" exchanges .25 Large State Enterprise Rights 
(see Appendix 4: LSER) for SMUs (Stock Market Units) at the Statutorily 
nominal price of 1 SMU per LSER. Since it is bracketed by SECURITY trans- 
actions, the SMUs are contained in the Social security" portion of the portfolio. 
If in addition there is a freely transferable SMU allocation of 1 per citisen, this 
corresponds to a statutory set-aside of 20% into the restricted "social security* 
portion of a citizen's portfolio.] 

SECURITY: 1 :':: 
ACQ:V:DILEVR;00-10:2.$ 

ACQf^rPAYOUTjFNBRjeO^N^tSyoiSMUzO:.!:: 
SECURITY:':':: 

[Exchange .1 SMU of the "social security" portfolio at prevailing prices for in- 
dexed debt in government LEVR, attempting to obtain the highest yield within 
the maturity interval 2000 to 2010, but no less than 2.5% above inflation. Ex- 
change another .1 SMU for a lifetime annuity starting at age 60 without right of 
survivorship, payable monthly by FNBR, if the implicit interest rate is at least 
5%.] 

Notes: 

1. The SECURITY transaction is only valid for citizens (whose first digit in the 
ID code is a 1 or 2) or for the government. 

2. Matching SECURITY transactions, and the transactions which they bracket, 
are considered a sub-block and kept intact throughout the merge-sorting of the 
Transaction Data Base (XDB). 
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3. Initially, TRANSFER and DELEGATE commands are invalid within a SE- 
CURITY sub-block, so that the government maintains custody over, and the 
individual citizen maintains investment authority over, the "social security" 
portfolio. 

4. In cases of hardship justifying immediate distribution of part of the "so- 
cial security" account, ACQUIRE transactions in exchange for "value received" 
(VAL) would be entered for a citizen's portfolio directly by the government 
welfare agency authenticating the situation and paying out the proceeds. 
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TRANSFER (XFER T) 
Syntax: 

TRANSFER:dateentered:as of date:financial institution acronym:asset:amount:: 

TRANSFER directs that the specified amount of the indicated asset be trans- 
ferred to the financial institution identified by "acronym." This transfer will 
take place at the completion of the processing cycle,, via the Disposition File 
(see Appendix 2: PASS5, and Appendix 1: DF - Disposition File). While 
the TRANSFER asset amount can be expressed as a percentage of portfolio 
contents, PASS5 translates that to an absolute amount prior to writing the 
information to the Disposition File. 

Examples: i 

XFER:V:MLPF:ESTLI:100%:: 
XFER:V:MLPF:SMU:50%:: 

[Transfer 100% of the portfolio stock of enterprise STL1, and 50% of the SMUs, 
to financial institution MLPF.] 

XFER:V:DBNK:FCDM:100%:: 

[Transfer 100% of the portfolio deutsche marks to financial institution DBNK.] 
Notes: 

1. The financial institutions must be authorized to act as custodians of that 
type of asset (see Appendix 2: Included Module - FINOK). 

2. When alternative, non-governmental financial institutions become authorised 
to act as custodians of entire portfolios, transactions of the form: 

XFER:V:MLPF:ALL:100%:: 

would become valid. This will provide a vehicle whereby particularly large or 
active portfolios could be removed from the general processing system, reduc- 
ing its overhead and enabling investment transactions more frequent than the 
general investment cycle. 
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WHEN (W) 
Syntax: 

WHEN rent ered date:as of date:: 

WHEN sets the entered date and the "as or date. 

Example: 

REINVEST:930216:930215:ALL:60%: 
SMU:20%:DLEVR;96:5%:DLEVR;97:5%:DLEV^ 

CXL:940125:940125:PREV:: 
REINVEST:940125:931231:ALL:60%: 

SMU:20%:DLEVR;96:5%:DLEVR;97:5%:DLEVR;98:5%:FCUS:5%:: 
NOTE:V:Reinvest record replaced because more than 100% allocated, so deleted 
from last field to reach 100%.:: 
WHEN:930215:930215:: 

[In this sequence, the original REINVEST record was erroneous. During the 
processing cycle, it is canceled (rather than merely dropped, in order to main- 
tain a complete audit trail) and replaced, and the date is then reset with the 
WHEN command so as not to affect subsequent transactions.] 



Appendix 4: Asset Categories 



Page 

75 ALL All Assets 

76 DXXXX Debt 

78 DIXXXX Indexed Debt 

79 EXXXX Enterprise Stock 

80 FCXX Foreign Currency 

81 PAYOUT Cash or Annuity 

83 SMU Stock Market Unit 

84 SMU2 2nd tranche SMU 

85 VOUCHER Privatization Voucher 

86 Virtual Assets: 

86 DR Donation Rights 

87 LSER Large State Enterprise Rights 

88 SSER Small State Enterprise Rights 

89 TR Testamentary Rights 
91 VAL Value Received 
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ALL: All Assets 



This asset category corresponds to the composite of all the assets in a portfolio. 
Note that this is an invalid asset to bid for (as "assetl* in an ACQUIRE record), 
and must be used with a price of "0" (Le M offering the portfolio assets at the 
market prices to be determined) when used as "asset2" in an ACQUIRE record. 



DXXXX: Debt 



Syntax: 

:DXXXX;YY;rr: 

Debt is a portfolio asset of the lender (and corresponding liability of the bor- 
rower). Acronym XXXX specifies the borrowing entity, and fa restricted to 
governmental entities, financial institutions and enterprises. 

The year of maturity is specified by YY, with *D* corresponding to a demand 
loan. A demand loan would be appropriate if the lender deposited cash with 
the expectation of purchasing other financial instruments at the next investment 
cycle. At maturity, the proceeds are invested in liquid debt of the state (e.g., 
DLEVR;D) at prevailing interest rates. The simple annual interest rate of the 
debt instrument is specified by rr, which is an optional subfidd when entering 
transactions unless needed to resolve ambiguities between debt instruments in 
a portfolio. 

Offers to lend in an ACQ transaction must be matched up with a correspond- 
ing offer to borrow in order to be consummated. Matching requires identical 
acronyms and either identical or overlapping maturities. 

During the second processing pass through the final sorted Transaction Data 
Base (XDB), PASS2 approximates the amount of offers to lend by acronym, 
maturity and price, and a (brief) opportunity is made available to potential 
borrower-entities to update any offers to borrow with appropriate ACQ trans- 
actions. This enhances debt management capabilities. Module PASS5 calculates 
the debt interest rate rr from the bids and offers and posts it to the updated 
XDB. 

Prices are specified as the simple annual interest rate of the debt. 

Example: 

:DLEVR;01: 

(Debt of LEVR to mature in the year 2001.] 
Notes: 

1. The year of maturity can be selected according to the personal circumstances 
of the lender. This may increase the attractiveness of debt and therefore the 
amount invested in it. However, a borrower can choose to manage its debt by 
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bidding only foi specified maturities (e.g., 5, 10 and 20 years), presumably with 
appropriate public notice. 

2. In the future, it may be desirable to allow specification of maturity intervals, 
within which the processing system attempts to maximise the yield, to smooth 
out the yield curve. Since a steep yield curve (with yields quickly increasing 
as maturities lengthen) is often associated with fiscal stimulus and inflation, 
and an inverted yield curve (with short-term yields above long-term yields) is 
often associated with tight money triggering a recession, a tendency toward a 
smoother yield curve may not only facilitate debt management but also economic 
stabilization. 
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DIXXXX: Indexed Debt 



Syntax: 

:DIXXXX;YY;rr: 

The indexed debt instrument DIXXXX is exactly analogous in all respects to the 
nn-indexed debt instrument DXXXX, with the exception that interest rates are 
expressed in -real" terms (Le., after inflation as estimated by an index specified 
by statute or decree). 

Note: 

If a financial institution accepts indexed deposits, account holders have an infla- 
tion hedge. If the financial institution in turn lends those funds to enterprises as 
indexed debt with an interest rate markup, it is also hedged against inflation. 
The enterprises would then presumably conduct their operations in a way to 
cope with prevailing inflation. 
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EXXXX: Enterprise Stock 



Enterprise stock represents shares in enterprise XXXX. For privatised large state 
enterprises, shares are tradeable only after approval of the corresponding priva- 
tization business plan (PBP), and the sale of compensation stock is prohibited 
until after certification of achievement of the demonopolization goals contained 
in the PBP. (See the OVERSIGHT command in Appendix 3.) 

Prices are specified in local currency per share. 
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FCXX: Foreign Currency 

This asset represents foreign currency for country XX, e.g., U.S. dollars (FCUS) 
or deutsche marks (FCDM). Other currencies can be readily added. 

The foreign currency is expected to be held in a liquid account yielding an 
appropriate rate of interest. 

The price is specified as local currency per foreign currency. 
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PAYOUT: Cash or Annuity 



Syntax: 

:PAYOUT;government or financial institution acronym; 
begin;end;survive;frequcney; 

implicit interest rate;actuarial table #;periodic payment: 
PAYOUT designates a generalized annuity. 

One option is cash, available to the portfolio owner (after the processing cycle is 
completed) from the financial institution specified in subfidd 2. Cash is specified 
by setting the begin and end times equal, and on or before the "as oP date of the 
processing cycle. However, this would presumably be an inappropriate option if 
demand deposits (DXXXX or DIXXXX) were available through an acceptable 
financial institution. 

The alternative is a stream of payments over an interval with a specified begin- 
ning and end, an "annuity." The beginning can be specified as a date (year, 
month and date, in the form yymmdd) or an age in years(in the form XX). 
The end can be specified as a date, an age or death (specified by D). If the end 
is specified as a date or an age, the portfolio owner can also specify whether 
the payments should continue upon his or her death. The default of payment 
termination upon death, with higher payout amounts, can be overriden with an 
S in the "survive" subfidd (otherwise the subfidd is left empty or filled with N). 
Unless the portfolio owner is an individual, begin and end dates cannot be ages 
and an S is used irrespective of the entry in the "survive" subfidd. Payment 
frequency can be specified as annual (A), quarterly (Q), monthly (M), or weekly 
(W). 

The annuity payment amounts are calculated by module "ACTUARY", taking 
into account standardised survival tables. If a government is acting as principal, 
actuarial shortfalls can be covered off-budget by the SMUs or enterprise stock 
kept in its social welfare account; actuarial windfalls can likewise be credited to 
that account. Financial institutions acting as prindpals could perhaps contract 
with the government for actuarial insurance backed by that same account also. 

The price of an annuity is specified as the implicit rate of return assuming a 
particular actuarial table. Module PASS5 determines the execution price of 
a transaction from all bids and offers, and then posts it, the identifier of the 
corresponding actuarial table and the periodic payment amount as the last three 
subfidds of the PAYOUT asset (which are unneeded if unnecessary to resolve 
ambiguity) to the updated Transaction Data Base (XDB). 
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Note: 



The annuity can be considered to be indexed to the inflation rate (see discussion 
under asset DIXXXX), or an additional instrument PAYOUTI can be created 
to serve that purpose. If the annuity is indexed, then the implicit rate is the 
"real" return (with inflation factored out). In this case, the financial institutions 
make available payment streams which vary with future inflation. 
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SMU: Stock Market Unit 



Stock Market Units (SMUs) are created by legislation ot decree. A SMU incor- 
porates one share of each large state enterprise privatised by the end of 199X 
(e.g., 1995), where X is specified in the legislation or decree. "Privatisation* 
occurs npon the "privatisation date" specified in an approved privatisation busi- 
ness plan submitted by an enterprise. 

Note that stock ownership rights to SMUs (see Virtual Asset: Large State 
Enterprise Rights) which incorporate rights to shares in enterprises privatised 
by a future date certain are created immediately by the legislation or decree. 



Prices are specified in local currency per SMU. 
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SMU2: 2d Tranche of SMUs 



SMU2s ate analogous to SMUs, and are also created by legislation or decree. A 
SMXJ2 incorporates one share of each large state enterprise privatised between 
199X and 199Y, where X corresponds to the cut-off for inclusion of enterprise 
stock in a SMU, and Y is the corresponding SMXI2 cut-off. X and Y are estab- 
lished by legislation or decree. For example, SMUs could comprise one share 
of each large state enterprise privatized by the end of 1995 (about a three year 
period), while SMD2s could comprise one share of each large state enterprise 
privatised from the beginning of 1996 to the end of the year 2000 (a five year 
period). 

Prices are specified in local currency per SMV2. 
Notes: • 

1. To encourage early privatisation, executive and board compensation set by 
statute or decree can be more attractive for earlier privatisation. 

2. To prevent useless speculation, an initial moratorium (e.g., one year) on 
trading SMU2s could be imposed. During such an interval, there would likely 
be little reliable information with which to value such a deferred asset, and it 
is unclear what near-term utility enhanced price discovery for SMU2s would 
provide. 
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VOUCHER: Privatisation Voucher 



The privatisation voucher is authorized by legislation or decree. In the context 
of appropriate enabling regulations, it is possible to interpret it as the right 
to one dtisen's share of the publicly distributable capital of each large state 
enterprise privatised by the end of 199X, where X is specified in the legislation 
or decree. It is the physical analogue in script form of the Stock Market Unit 
(SMU) asset on the Privatise!™ system. 

A typical transaction redeeming a physical voucher for a Stock Market Unit 
could be: 

ACQ:921201:931231:SMU:S:VOUCHER:S:1:: 
ACQ: , :931231:ESTLI:2000:SMU:0:.6:: 

(The first transaction, entered on December 1, 1992 and taking effect as of 
December 31, 1993, exchanges one privatisation voucher for one Stock Market 
Unit (SMU) at the statutorily nominal price of 1 SMU per VOUCHER. The 
second transaction, entered on the same date, places a bid for shares in enterprise 
STLI at a price not to exceed 2000 (local currency), using the proceeds of half 
the Stock Market Unit liquidated at the market price effective on December 31, 
1993.] 
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Virtual Asset: Donation Rights (DR) 

Donation rights are "transferred* to a donor in exchange for a gift, and are 
perhaps better described as a "donation privilege." 

Cross-prices are a statutorily nominal 1 Whatever per DR. 

Example: 

ID:921015:921015:19601120JSMXYJKLM:: 
ACQ:V:DR:S:SMU:S:.l:: 
ID:V:60100001CVNXYSOSV:: 
ACQ:V:SMU:S:DR:S:.l:: 

[The individual specified by the first ID record has donated .1 SMU (at the 
Statutorily nominal price of 1 SMU per DR) to the charitable institution spec- 
ified by the subsequent ID record. A donation must be entered as a contiguous 
matched pair including donor and donee. Module XACT will sort the transac- 
tions for eventual incorporation into transaction blocks containing the complete 
set of transactions for each ID. However, in the case of a donation, XACT will 
also generate "documentation" notes. A note containing a done of the donee 
ID record will be inserted immediately following the donor's ACQ record. An 
analogous note containing a done of the donor ID record will be inserted im- 
mediately following the donee's ACQ record.] 
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Virtual Asset: Large State Enterprise Rights (LSER) 

Large state enterprise rights are created by statute or decree, for instance when 
Stock Market Units (SMUs or SMU2s) are brought into being. 

Cross-prices are a statutorily nominal 1 Whatever per LSER. 

A typical initialisation transaction for a citizen would be: 

ACQ:921201:921231:SMU;S:LSER:S:1:: 

[This transaction, entered December 1, 1992 and taking effect as of December 
31, 1992, would exchange 1 LSER (Large State Enterprise Right) for SMUs 
(Stock Market Units) at the Statutorily nominal price of 1 SMU per LSER. 
Note the implicit transfer, from the state as trustee or from the government as 
custodian, of the Large State Enterprise Right.] 
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Virtual Asset: Small State Enterprise Rights (SSER) 

These rights in small state enterprises such as shops or small busies we 
«an\ed an individual or enterprise in return for some exchange such « acom- 
Snttion of cash, a mortgage or a contractual commitment to mamtain a certain 
^workforce w\th specified salaries and benefits Typ caHy, 
be auctioned by a local governmental entity, which could be entitled by statute 
S a p^elgl of the bid and so would be motivated to dev«* • strategy £ 
its combined value. An individual could also bid . portion of the 
SMUs (Stock Market Units) in his or her portfolio. 

Cross-prices are a statutorily nominal 1 Whatever per SSER. 

For example, assuming SMUs are legislated into being on October 1. 1992 
even before they are "operationalised" an individual's current be 
transferred as part of a successful bid for a small state enterpnse as follows. 

ID:921015:921015:196011203SMXYJKLM:: 
ACQ:921015:921015:SSER:S:SMU:S:.5:: 
ID:V:903M005LGGXYLOCG:Local Government:: 
ACQ:V:SMU:S:SSER:S:.15:: 

ID:V:90304000RGGXYREGG:Regional Government:: 
ACQ:V:SMU:S:SSERiS:.l:: 

ID:V:90300000LRGXYLEVR:Leviathan Republic:: 

ACQ:V5MU:S:SSERiS:.26n . 

^October 16, 1992, an individual (specified in the ^J?™"**^ 

ferred .5 of his SMUs as part of a successful bid for rights in a small state 

enterprise. These SMUs are transferred 30% to the local go vernment ananpng 

Action, 20% to the regional government .and 50% 

all transactions occur at the Statutorily nominal price of 1 SMU per SSEK-J 
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Virtual Asset: Testamentary Rights (TR) 

These are transferred from s legatee "to* a deceased individual in exchange 
for a bequest, as certified and entered by appropriate local authorities after 
* processing any will or conducting any "probate." 

Cross-prices are a statutorily nominal 1 Whatever per TR, 
Example: 

ID:930815:930715:19431120JRMXYABCD:: 
ACQ:V;TR:S:ESTLI:S:1000:: 
ID:V:19630704MRMXYBCDE:: 
ACQ:V:ESTLI:S:TR:S:1000:: 

NOTE:Bequest of 1000 shares of STLI from JR to MR,:: 

ID:V:19431120JRMXYABCD:: 

ACQ:V:TR:S:ALL:S:50%:: 

ID:V:19460630ERFXYCDEF:: 

ACQ: , : , :PAYOUT;FNBR;940101;D;N;M:S:TR:S:50%:: 

NOTE:50% of the portfolio balance is to be liquidated on behalf of ER to 
purchase a lifetime annuity through FNBR payable monthly without right of 
survivorship.:: 

XD:V:19431120JRMXYABCD:: 

ACQ:V:TR:S:ALL:S:30%:: 

ID:Y:19830210LRFXYDEFG:: 

ACQ: , : , :PAYOUT;FNBR;940101;030101;S t A:S:TR:S:30%:: 

NOTE:Another 30% is to be liquidated on behalf of LR to purchase a 9 year 

annuity from FNBR payable annually, with a right of survivorship.:: 

H):V:19431120JRMXYABCD:: 
ACQ:V:TR:S:ALL:S:20%:: 
ID:V:60100001CVNXYSOSV:: 
ACQ:V:DFNBR;D:S:TRS:20%:: 

NOTE:The remaining 20% is liquidated on behalf of charitable institution SOSV, 
and transferred to it as liquid assets deposited in FNBR.:: 

Notes: 

1. Bequests will generally be liquidated and then used to purchase assets such 
as PAYOUT or DXXXX;D (to avoid the significant difficulty of transferring 
percentages of an entire portfolio intact). The exception is when fixed (non- 
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percentage) amounts of specific assets (such as enterprise stock, in order to 
preserve control) are transferred. However, the nature of the processing cycle 
and serial storage media make it difficult to verify that the asset actuaUy exurted 
in the specified quantity in the portfolio of the deceased. Therefore, the legatee 
may assume any risk associated with entering a transaction involving that asset 
which must be subsequently "reversed.") 

% As in the treatment of Donation Rights, appropriate -documentation" notes 
will be generated prior to sorting the transactions by ID. 
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Virtual Asset: Value Received (VAX) 



This asset is a placeholder representing value received outside the Privatise!™* 
system. 

Cross-prices are a statutorily nominal 1 Whatever per VAL. 
Example: 

ID: V:ID code of new stock subscriber # 1:: 

ACQ:Y:ENEW:S:VAL:S:1000:: 

ID:V:XD code of new stock subscriber # 2:: 

ACQ:V:ENEW:S:VAL:S:500:: 

n):':':ID code of new stock subscriber # 3:: 

ACQ:V:ENEW:S:VAL:S:20:: 

(This series of transactions, only entered by enterprise NEW itself (as authen- 
ticated by an appropriate government agency such as the Privatisation Board) 
transfers a total of 1,520 shares of stock to three subscribers.] 

Note: 

Acquiring any asset in the Privatise!™ system in exchange for value received 
outside it requires satisfactory documentation and authentication. 
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Appendix 5: Individual Transaction Entry Form 

ID Name: , 

address: • — — — 

telephone* . . 

supplemental 

name: — — — — — — — — 

code: _______ — — — — — — — - 



Portfolio account: □ Regular 

□ Social Security 



DELEGATE — ° ^vestment 

delegatee-acronym O voting 



□ Earnings 



% compensation □ Assets 

ELSE:ACQ _ — — - — — : — m * 

bid-for asset bid price offered asset offer pnee amount 



REINVEST 



asset 



% asset % «ssct % 



TRANSFER 

financial institution 



asset 



amount 
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ACQUIRE 
ELSE:ACQ 














1/1(1 pXICC 




VI i U J* Jt 11»^ 


amount 


bid-for asset 


bid price 


offered asset 


offer price 


amount 


ACQUIRE 
ELSE:ACQ 












Dltt-lUX 058CI 


wlU pncc 


nflfcred asset 


offer nriee 


amount 


bid-for asset 


bid price 


offered asset 


offer price 


amount 


ACQUIRE 
ELSErACQ 












bid-for asset 


bid price 


onexcu asset 


oner pnee 




bid-for asset 


bid price 


offered asset 


offer price 


amount 


ACQUIRE 
ELSE:ACQ 












bid-for asset 


bid price 


offered asset 


offer price 


amount 


bid-for asset 


bid price 


offered asset 


offer price 


amount 


Portfolio Owner 


date 








official #1 


title 


date 








official #2 


title 


date 
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Appendix 6: Report Formats 
Disposition Report (generated by DISPOSE) 



Custodial financial institution name 

address 

phone 

supplementary name 
(ID code) 

Recipient #1 name 

address 

phone 

supplementary name 
(ID code) 
assetl amountl 
•*• 

assetn amountn 



Recipient #N name 

address 

phone 

supplementary name 
(ID code) 
assetl amountl 
••■ 

assetn amountn 



I 
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Lending Report (generated by PASS2) 



Potential borrower name 

address 

phone 

supplementary name 
(ID code) 



Approximate amount of loans offered at specified maturities and interest rates: 

Maturity #1: Year = 
Demand amount 
1% amount 

X% amount 



Maturity #N: Year = 
Demand amount 
1% amount 



X% amount 
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Warning Report (generated by AUCTION) 



Potential over-transferor #1 
ID record (short form) 
•or. 

Transaction block (long form) 
Apparent amount of SMU transfers 



Potential over-transferor #N 
ID record (short form) 
•or. 

Transaction block (long form) 
Apparent amount of SMU transfers 
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Appendix 7: Transaction Errors 
ELSE contains transactions other than ACQUIRE. 

ELSE Mowing ACQUIRE has "same* asset pairs. For the purpose of this 
comparison, all debt of any particular entity is considered to be the "same" 
irrespective of maturity. 

ELSE follows transaction other than DELEGATE or ACQUIRE. 
Invalid asset in this context. 

Debt instrument cannot be nsed by non-issuer as a asset2 w in ACQUIRE trans- 
action. 

Invalid command for this type of entity: 

1. BANK can only be entered by an enterprise. 

2. DELEGATE cannot be entered by a ddegatee-organisation except for pro- 
prietary assets. 

3. DIVIDEND can only be entered by an enterprise. 

4. FILTER can only be entered by a delegatee-organization. 

6. GRADE can only be entered by a financial institution coded as an evaluator- 
organization. 

6. JOIN and LEAVE can only be originally entered by an enterprise, though 
they can be validly posted to an individual transaction block. 

7. OVERSIGHT can only be entered by the appropriate government agency 
(e.g., Privatisation Board). 

8. PERCENTAGE can only be entered by delegatee-organisations. 

9. SECURITY can only be entered by a citizen, or by the government. 

Invalid command in this context. 

1. TRANSFER and DELEGATE commands invalid within SECURITY sub- 
block. 

Unmatched FILTER command. 
Unmatched SECURITY command. 
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Section 1. Introduction 



Privatization Planner (tm) implements a truly adaptive knowledge 
base. Users can review, evaluate and contribute to the 
structured information. Their contributions are in turn 
evaluated by other users. Such evaluations determine which 
portions of the knowledge base survive into future generations. 
This software technology is a tool which transforms the knowledge 
of a user community into a dynamically growing and evolving 
knowledge base. 

Privatization Planner (tm) also incorporates a process to 
effectively access knowledge base entries. For example, assume 
that one node of the knowledge base is a bibliography containing 
thousands of books or articles as subtopics. The first access 
technique is via hierarchical topics, distinguished by allowing 
pages of information to be associated with each topic mode and 
not just the terminal nodes. Once the bibliography topic is 
selected, the challenge remains how to effectively access the 
thousands of subtopics. 

A very large number of (for example) bibliographic subtopics can 
be effectively accessed by (see the Order command): 

1. Finding all works posted after a given date; 

2. Finding all works matching a given set of keywords; 

3. Selecting only those works previously evaluated within 
a certain range by a specified user or users; 

4. Selecting only those works whose actual or estimated 
evaluation by the user himself or herself is within a 
certain range ; 

5. A combination of the above choices. 



The selected subtopics can also be sorted by date, other user(s) 
evaluations, or actual /estimated evaluations of the user himself 
or herself. 



Privatization Planner (tm) can be implemented on diskette or other 
physically transported media, or by an electronic network. In 
either case, the implementation can be hierarchical, with nodes 
of computers collecting contributions and evaluations which are 
periodically aggregated by the computer at the parent node. The 
preferred implementation is a combination of both approaches, 
with physical media periodically integrated into an electronic 
network knowledge base. 
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Section 2. Operation of Privatization Planner ftrn 



A, From the Perspective of an Individual User 



Access to the hierarchical knowledge base is provided either by 
an electronic network or by physical media such as diskettes or 
CD-Roms. The user first copies the knowledge base onto a hard 
disk when available (for physical media rather than electronic 
network), and types "ndn". The system then displays a welcome 
screen, and prompts as necessary: 

Enter disk drive for ndn file [e.g., 'c:']: 

Enter directory of ndn file [e.g., 'ndn']: 

At this point, the program displays the top of the hierarchical 
"table of contents" in "page mode", and awaits user commands. 

Upon completion of the user's review, the knowledge base will 
include his or her evaluations and proposed changes. The user then 
copies the knowledge base back to diskette and forwards it to the 
system coordinator for compilation and analysis. 



P. From the Perspective of the System Coordinator 

The job of the system coordinator can be parsed into a series of 
tasks : 

i) The current version of the executable program file and the 
hierarchical data base is made available to a select set of 
interested and knowledgeable users. 

ii) The users explore those portions of the data base which are of 
relevance and interest to them. In the process, they have the 
ability to enter their opinions for the values of variables, to 
evaluate and comment on topic layouts and page contents, and to 
propose additions, replacements or deletions to topics and/or 
pages . 



iii) For physical media users, those media are returned to the 
system coordinator, who aggregates them by copying directories and 
files onto a disk partition, and then onto a composite diskette or 
diskettes. The composite diskette(s) are then redistributed for 
evaluation and comment. Note that if necessitated by the quantity 
of information, different subsets of the composite data base can be 
distributed to different users based on their expressions of 
interest for this evaluation phase. 



A set of diskettes is then prepared for each contributor, including 
his or her own topic setup and page contents, and all the feedback 
it generated (evaluations, comments and entries for values of 
variables). This contributor is then given an opportunity to make 
modifications based on that feedback, and return a new version to 
the system coordinator. 

iv) The system coordinator again copies directories and files onto 
a disk partition, and then runs the following modules when 
available: 

— "vacuum", which cleans out all unused files and directories; 

— "evaluate", an optional step which tags the nodes of the 
hierarchical data base with values calculated according to the 
scoring parameters and algorithms then in effect; 

— "select", which copies to diskette(s) several versions: the 
optimal (default) version of the hierarchical knowledge base, 
contributions from the H highest-evaluated users, and contributions 
from other users as a probabilistic function of their evaluations 
and the user's interest in those topics. 

v) The selected versions are then distributed at the start of a new 
"generation's corresponding to step (i). 

vi) The security system for diskette (or other physical medium) 
amounts to transmission to and from known users. The software 
supports the ability for each distributee to circulate the original 
diskette or a copy of it among additional users (who would have the 
same ability) . 

However, since all the users of a given physical diskette would 
have the ability to alter or override each other's responses, this 
should be limited to knowledgeable and interested persons in a 
position of privity to the original distributee. 

In addition, where the system is used in a "closed end" automatic 
optimization mode, where the evaluations of a known set of users 
determine the versions preserved into subsequent distribution 
cycles, if the distributee includes additional users then a single 
"optimal" representation of the distributee's entire group can be 
formulated. 

For implementation on an electronic network, physical distribution 
of diskettes is unnecessary and standard security procedures for 
access and login would apply. In addition, an on-line system can 
make available to each user the entire knowledge base and all 
proposed contributions. 



3. Description of User Cojpiands 



The adaptive knowledge base is organized into topics and pages, 
with two corresponding modes of operation. In topic mode the 
hierarchical organization of topics covered in the system can be 
displayed and altered. It can be thought of as an interactive, 
hierarchical table of contents. In page mode the contents of pages 
of information relevant to the current topic within the 
hierarchical knowledge base can be displayed and altered. The 
topic can be thought of as part of the table of contents, while the 
pages are the actual information addressed by that table of 
contents . 



A, Command Summary 

A Add a topic or page (e.g., A2 adds before second one). 

B Back to previous screen of topics, if can't fit on one screen. 

C Customize user's setup. 

0 Delete a topic or page (e.g., D2 deletes second one). 

E Evaluate a topic or page (prompts for 1-5 rating and comment). 

F Forward a screen of topics (when can't fit all on one screen). 

G Goto a previously Labelled topic (e.g., Gbiblio). 

H Help explains available commands. 

1 Interest level in topic (II: no interest, 15: most interested). 
J eject page from laser printer. 

K Keyword definition or invocation. 

L Label the current topic (e.g., Lbiblio) . 

M Map display of current region in data base. 

N Name the current topic differently. 

0 Order the current subtopics (i.e., filter and sort). 

P Page. Switch to Page mode, or display Page X (e.g., P2). 

Q Quit the knowledge base. 

R Replace topic or page (e.g., R2). 

S Simulate the Privatize! (tm) computerized marketplace. 

T Topic. Switch to topic mode, or display topic (e.g., T2). 

U User. Topic/page version in topic mode. Values in page mode. 

V Values. Entry of user-specified values embedded in pages. 

W Write a message to a specific user or set of users. 

X exit Customize, Help, Map, Order, Simulate & Write commands. 



£j ppputnQnfratiQn of commands 



Syntax: A or Axx 

where xx is between 0 and the number of topics or pages available 
at this level in the hierarchy. 

This command allows a user to add a topic or page at the current 
level in the hierarchy. 

A appends a new topic or page after existing topics. 

Axx adds a new topic or page before number xx, except "AO" is 
equivalent to "A". 

After creating a new topic, the user is prompted to enter its name. 



Error condition: 

1. If xx specifies an unavailable topic or page, the user is 
notified and prompted to try again. 

2. While one user may view another user's topic organization or 
page contents, modification of them is not allowed. 



^acK (and Forward) 

Syntax: B or Bxxxx; F or Fxxxx 

If there is a large number of subtopics at a given node, the Back 
and Forward commands allow a user to effectively move through them. 

For example, if the user is currently displaying the 500th to 520th 
subtopics, then issuing B will reposition the display to the 480th 
to 500th subtopics, and issuing B15 will reposition the display to 
the 15th to 35th subtopics. 

If the user is currently displaying the 1200th to 1220th subtopics, 
issuing F will reposition the display to the 1220th to 1240th 
subtopics, and F2000 will reposition the display to the 2000th to 
2020th subtopics. 
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Custpjrii2e 
Syntax : C 



Customize allows a user to tailor system options to his or her 
preferences. It can be invoked immediately after login, or at any 
time subsequently from any directory topic and is terminated with 
the exit command. System default options are overridden when the 
user enters new options. The user's choices are given effect for 
the current directory and all subdirectories, unless overridden by 
a later customize command. A system parameter determines whether 
or not a Customize command for a given directory overrides 
previously entered Customize commands for its subdirectories. 

Customize is implemented by copying into the current directory (if 
not previously copied) a template Customize subtopic of the System 
topic in the root directory, along with an explanatory page with 
embedded values for different options. 

The specifiable options, which the system prompts for, include: 

1. Identification of user contributions, which allows a 
user to remain public (the default), have the system 
select an alias by which his or her contributions can 
be accessed by others, or to become private to prevent 
access by others. 

For example, a user could choose to be private for a 
particular bibliography directory while developing and 
implementing a new keyword design, and then go 
public at a stage suitable for review by others. 



2. Changing parameters "alpha", "beta" and "gamma" used to 
correlate user evaluations to evaluations entered by 
others. For a description of these parameters, see 
the documentation of the "Order" command. 

3. For diskette (and other physical media) users (rather 
than electronic network users), specifying the type of 
medium (physical size and storage capacity) and the 
maximum number (e.g. of diskettes) to be sent. If the 
entire knowledge base and all proposed alternatives 
exceed this size, topics of no interest will be 
excluded and alternatives will be probabilistically 
included as a function of the user's interest level 

in particular topics (see the Interest command). 



Delete 
Syntax : Dxx 

where xx is between 1 and the number of topics or pages available 
at this level. 

This command allows a user to delete a topic or page in the current 
level in the hierarchy. 

Error conditions: 

1. If xx specifies an unavailable topic or page, the user is 
notified and prompted to try again. 

2. While one user may view another user's topic organization or 
page contents, modification of it is not allowed. 



Evai 

Syntax : E 

This command allows a user to evaluate the organization of the 
current topic or the contents of the current page, and to enter any 
comment on it. 

The program first requests an evaluation as follows: 
Please evaluate this topic/page (1 = very poor, 5 = very good): 



The user has the option to enter a number from 1 to 5 (3 being 
neutral ) . 

The program then requests any comment: 

Please enter any comment on this topic: 

The user then has the option -to enter a comment, terminated by a 
"carriage return" or "enter" keystroke. 



Error condition: 

If the logged-on user is in his or her own setup, the Eval command 
is unavailable. 



Forward 

Syntax: F or Fxxxx 

See the Back command for a description of the Forward command. 



Goto 

Syntax : Gxxxx 

The Goto command repositions the user at the node in the 
hierarchical knowledge base previously "Labelled" as xxxxx. 
Therefore, it is convenient to Label topics which a user expects to 
return to repeatedly. Labels which begin with the character "." are 
considered temporary, in the sense that they can be overwritten 
without warning if the space is needed by new labels. 

Labels are stored in the page(s) associated with the Label subtopic 
of the System topic in the root directory. The user can directly 
review the labels by selecting this Label subtopic and switching to 
page mode. This is how the user chooses which permanent label (s) 
to delete (by blanking the label field) when all slots are so used. 

Error condition: 

Attempting to define a new label after more than a predetermined 
number (initially set to 20) of permanent labels has been defined 
for a particular user. 

Help 

Syntax: H or Hx 

The Help command provides on-line documentation of potential 
commands to the user. It is terminated by the exit command. 

H positions the user in the Help subtopic (of the System topic in 
the root directory), which displays a list of commands with brief 
descriptions which the user can select in order to inspect their 
page(s) of documentation. 

Hx positions the user directly in the starting page of 
documentation for the subtopic associated with command x. 



Interest 

Syntax: I or Ix 

The Interest command allows a user to specify his or her degree of 
interest in a topic and its subtopics. If the user enters I, the 
system prompts for the interest level x (1 indicating no interest, 
5 the most interest ) . 

For a diskette (or other physically transported medium) user, if 
the knowledge base size exceeds the maximum number of diskettes 
specified in the Customize command, then topics of no interest will 
be excluded and alternatives will be probabilistically included as 
a function of interest level in particular topics. 



Keyword 

Syntax: K (or Kxxxx, etc. see below) (from topic), or: 
Kxxxxx=S Kxxxx=U Kxxxx=yyyy (from subtopic). 

Keywords are generated or reviewed by entering the command K, which 
switches the user to the keyword topic in the current directory 
(copied from a template in the root directory when necessary). The 
keyword topic has an explanatory page with embedded values for 
different keywords, with keywords contributed by different users 
accessible via the User command just like other embedded values. 
Keywords defined in the root directory are accessible from any 
subdirectory, but keywords defined in a "keyed" directory other 
than the root apply only to immediate subdirectories. 

The command Kxxxx (or Kxxxx=S?) from a topic will filter out all 
subtopics which do not match keyword xxxxx; the command Kxxxx- (or 
Kxxxx-S? or Kxxxx=U?) filters out all subtopics which do match 
keyword xxxxx; the command Kxxxx=yyyy? filters out all subtopics 
which do not match the yyyy value for keyword xxxxx; and the 
command Kxxxx-yyyy? filters out all subtopics which sis match the 
yyyy value for keyword xxxxx. Successive keyword commands before 
moving up and out of the "keyed" directory successively filter out 
additional sets of subtopics. 

The entry for each keyword consists of the keyword itself, a 
description of its meaning, and an optional boolean text 
specification. This specifies those words which must be present or 
not in the subtopic 's name or page information in order for it to 
be accessed by the keyword. However, this "first approximation" of 
whether a particular subtopic matches a particular keyword can be 
overridden by entering: 

Kxxxx=S or Kxxxx=U 

from the particular subtopic itself, where xxxxx is the keyword, 
S is the flag for "Set" (meaning that subtopic will be accessed by 
the keyword) , U is the flag for "Unset" (meaning that subtopic 
won't be accessed by the keyword). Kxxxx=yyyy is issued in a 
subtopic for multi-value keywords (e.g., Kcountry=US) . 

Note that the evaluation by other users of a Keyword page applies 
not to the page itself, but rather to the keywords proposed by the 
user whose embedded values (keywords) are displayed. The keywords 
are ranked (e.g. , by summing the signed deviation of their 
evaluations from the average evaluation of 3 ) , and the best are 
then presented as future defaults. 



Label 

Syntax: L or Lxxxx, description 

The Label command works in conjunction with the Goto command. The 
Label command associates the location of the current node with the 
identifier xxxx, so that Gxxxx will return the user to that 
location. 

If the user enters L, the system prompts for the label itself and 
a brief description of the node. It will then place that 
information in page(s) associated with the Label topic in the root 
directory. 

Note: If the label xxxxx starts with a ".", it is "temporary" and 
subject to being overwritten without notice by new labels if there 
are no free slots. If the user requests a new label after all his 
or her slots are filled with "permanent" labels (not starting with 
" . " ) , the system requests that the user inspect the pages of the 
Label topic and blank out unwanted labels to free up space. 



Map 

Syntax : M 

The Map command displays the environment of a node by showing the 
ancestory of that topic up to the root directory. It is terminated 
with the exit command. 

Note: Subtopics are already listed when viewing a node in topic 
mode, and "siblings" can be seen by stepping up one level in the 
hierarchy with the T command. 



Name 

Syntax: N 



The user is prompted to enter a new name for the current topic. 

Note: to change the name of one of the subtopics of the currfent 
topic, that subtopic must first be invoked with the "Topic" command 
before using the "Name" command. While that subtopic could have 
been replaced without changing to it, its contents or "pages" of 
information would have been lost. 

Error condition: 



A user is not allowed to modify another user's topic. 



Order 

Syntax: O or Oxxxx 

The Order command supports filtering and ranking a large number of 
subtopics, using entry dates, keywords, other users' evaluations, 
and estimates of the current user's own actual or estimated 
evaluations. It is terminated by the exit command. 

Order is implemented by a subtopic of the System topic in the root 
directory, with an explanation page with embedded values for 
different choices. Oxxxx (where xxxxx has been defined in a 
previous Order command) results in the system performing the 
specified filtering and sorting on the subtopics of the current 
directory. O (or Oxxxx where xxxxx has not been previously 
defined) results in the system displaying the appropriate page with 
instructions . 

The first values to be entered are the label for this particular 
Order arrangement, and any optional description. Next, the user is 
prompted to enter the range of posting dates to consider (e.g., to 
check only previously-unreviewed subtopics). The next prompt is 
for those keywords which must all be matched. Alternatively, more 
general boolean logic could be used. The user then has the option 
to specify a range of evaluations in which he or she is interested, 
either by a specific user or all users averaged. Alternatively, 
specified subsets of users could be averaged. If the evaluation of 
a specific subtopic falls outside this range, it is filtered out. 
The next prompt is for the range of the user's own evaluation, 
either entered previously by the user or estimated from other 
users' entries by regression analysis (see section 5). 

Note that a user will be motivated to enter some evaluations, since 
only by correlating those entries with other users' evaluations can 
the system respond with an estimated evaluation for subtopics which 
the user hasn't yet evaluated. This also allows the system to post 
cross-correlations (between this and other users' evaluations), 
which can then be displayed and used as a sort key when selecting 
which other user's version to inspect. 

The user also has the option to multiple-sort the filtered 
subtopics by date of posting, evaluations by other users, his or 
her own actual or estimated evaluations, or by subfields of the 
subtopic name (such as title or author of works in a bibliography). 

Note: Alternatively, boolean combinations of date, other 
evaluations and user evaluation conditions can be supported. E.g.: 
date within the last week; AND ranked at least superior by a 
specific other user OR else by all users averaged; OR estimated to 
be ranked above average for the user himself or herself; with 
sorting by the user's own actual/estimated evaluations. 



Page 

Syntax: P or Pxx 

— Topic mode — 

In topic mode, the P command allows the user to switch from topic 
mode to page mode. (Topic mode is used to view or alter the 
organization or hierarchy of the information base, while page mode 
is used to view or alter the actual contents of a particular topic 
in the hierarchy . ) 



— Page mode — 

In page mode, the P command displays the next page, and Pxx 
displays page xx. The system notifies the user if the requested 
page doesn't exist. 



Quit 

Syntax: Q 

This command gracefully terminates operation of the program, 
returning the user to the operating system. 



Replace 
Syntax: Rxx 

where xx is between 1 and the number of topics or pages available 
at this level. 

This command allows a user to replace a topic or page in the 
current level in the hierarchy. 

Error conditions: 

1. If xx specifies an unavailable topic or page, the user is 
notified and prompted to try again. 

2. A user may view but not modify another user's topic organization 
or page contents. 



Simulate 
Syntax : Sxxxx 



This command allows a privatization policy-maker or policy analyst 
to participate in a simulation of the algorithms and processes of 
the Privatize! (tm) computerized marketplace. It is terminated by 
the exit command. 

If Simulation xxxxx has not yet been initiated, the system asks 
whether the user wishes to initiate a new privatization marketplace 
simulation by performing the role of "government". If so, the user 
is repositioned into the Simulation xxxx Setup subtopic (whose 
"ancestory" is root\Utility\Simulation\Simulation xxxx) . There, 
the user, as "government", specifies (as embedded values in the 
associated page(s)): 

— ids of eligible participants (or can allow anyone to 
participate) and optional "personae" ; 

ids and descriptions of eligible delegatee-organizations 
(when the Delegate transaction is supported); 
supported transactions and assets; 

initial endowment of participants and any subsequent 
privatization transfers (or levies like fees or taxes); 
default period of investment cycle (measured by time 
interval or cumulative number of submitted transactions); 

— general announcements to participants. 

Note that the individual participants and the government can 
communicate directly via the Write command. For example, a user 
wishing to be approved as a delegatee-organization could submit 
descriptive qualifying data. If the "government" approved, that 
user would be added to the list of delegatee-organizations. 

If a user- "government" has already set up Simulation xxxxx, then 
the user issuing the Sxxxx command is repositioned into the 
Simulation xxxxx topic and selects one of the following subtopics: 

1 Simulation xxxxx Setup 

2 Simulation xxxxx Price History 

3 Simulation xxxxx Portfolio History 

The Setup subtopic displays the simulation framework as specified 
by the "government". The Price History subtopic has pages of 
information containing asset price data for each investment cycle, 
calculated by periodically executing the Privatize! (tm) simulation. 
The Portfolio History subtopic has pages containing portfolio and 
transaction data, by user, for each investment cycle. The 
transaction data is tagged as consummated or not by the periodic 
simulation. In each case, the data is represented by embedded 
values under the "government" id, except for the portfolio history 
data under each user's own id. 



Topic 

Syntax: T or Txx 

— Page mode — 

In page mode, the T command switches the user to topic mode. 
(Topic mode is used to view or alter the organization or hierarchy 
of the knowledge base, while page mode is used to view or alter the 
actual contents of a particular topic in the hierarchy*) 

— Topic mode — 

In topic mode, this command allows a user to move about in the 
organizational hierarchy of topics. 

T steps up one level in the hierarchy by invoking the next higher 
topics . 

TO invokes the root topics at the top of the hierarchy. 

Txx selects the specified subtopic from among the displayed 
selections, where xx is between 1 and the number of available 
subtopics . 

Note: If the subtopic name begins with "EXECUTE xxxxx" , then 
Privatization Planner(tm) will store in a file the user's current 
position in the knowledge base (along with other information), and 
begin execution of program module xxxxx (for instance a gateway 
program into another information network or a market analysis 
program which charts prices or otherwise analyzes price history in 
support of trading decisions). Upon completion of program xxxx, 
the user types (at the operating system prompt) "RESUME", which 
reads the file updated by the EXECUTE xxxx subtopic in order to 
restore the user to the same position in the knowledge base . 

Error conditions: 

If xx specifies an unavailable topic, the user is notified and 
prompted to try again. 
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User 

Syntax: U or Uid; 

where id corresponds to the character string identifying a 
particular user. 

If "U" is entered without an id, the system presents the id and 
name of each available user (optionally sorted by cross-correlation 
with the requesting user), and provides an opportunity to select 
each in turn. 

If "U" is entered with an id, the system verifies the id is 
accessible and then presents information appropriate to that user. 



— Topic Mode — 

If the id specified in the "U" command does not correspond to that 
of the logged-on user, he or she will be prevented from executing 
Add, Replace, Delete or Name commands. 

On the other hand, if the id specified in the "U" command 
corresponds to that of the logged-on user, he or she will be given 
an opportunity to "adopt" the organization and contents, for the 
current topic, of either the default version or the version another 
user. 

The system first informs the logged-on user whether he or she 
already has a personally customized setup for the current topic. It 
then asks whether the logged-on user wishes to "adopt" as his or 
her own, and therefore accessible to future revision, the default 
topic organization and page layout or that of another user. 



— Page Mode — 

The User command in page mode allows the logged-on user, who is 
accessing the page contents of a second user's (or his or her own) 
topic setup as determined by the latest User command in topic mode, 
to view the entries of still a third user for the values of 
variables embedded in the page. 

While the User command in page mode does not invoke a different 
user's organization or contents, the form and usage are exactly 
analogous to that in topic mode. 



Values 
Syntax: V 



Each page can contain a series of variables embedded within the 
text, demarcated by a pair of braces "{•••}"• This command allows 
each logged-on user to enter his or her own judgment as to the best 
values for those variables. Each variable can be of arbitrary 
length and can take on the value of any sequence of alphanumeric 
characters . 

The program will highlight each variable in turn, and prompt the 
user for a new entry. The user need not enter a value for all or 
any variables. On the other hand, if a user's judgment should 
change, additional subsequent entries supersede earlier ones. 



Write 

Syntax: Wxxxx 

The Write command allows a user to send a message to a specific 
user. It is implemented using the Message subtopic of the System 
topic in the root directory, and is terminated with the exit 
command. 

The user types the message into a new page associated with a new 
entry at the Message node. This will be stored under the 
recipient's ID, and is the only time one user can alter information 
stored under another user's ID. The other user reads any messages 
by logging on, viewing the Message directory, and selecting 
messages to read from the list of subtopics. 

After reading a message, the recipient can respond to it with 
another Write command and delete it with the Delete command. 



exit 

Syntax : X 

The exit command terminates operation of the Customize, Help, Map, 
Order, Simulate and Write commands. 



4. Knowledge Base Adaptation 



A, Parameters Used to Evaluate Alternative Versions 

The scoring algorithms rely on the evaluation of topics and pages. 
Three parameters are used in the process of transforming the set of 
evaluations into composite scores. 

The first parameter relates to the issue of quality versus 
quantity. A purely "intensive" scoring system would score ten high 
quality pages of information equally to one such page. On the other 
hand, an "extensive" scoring system would score two mediocre pages 
twice as high as one. 

On the assumption that the value of the data base is a combination 
of its quality and quantity, the parameter "extensivity" achieves 
this as follows: 

value = (quality score) x (measure of quantity) A {extensivity } 
or 

value = (quality score) A (l-ext. ) x (measure of quantity) A (ext. ) 

where both the quality score and the measure of quantity are 
greater than or equal to one, and the extensivity parameter is in 
the range from 0 (i.e., only quality matters) to 1 (i.e., the score 
is proportional to quantity) . 

Parameter "content" fixes relative weights of organization and 
content: 

topic value= ("content ")x( evaluation of aggregated subtopic content) 
+ (1 - "content") x (evaluation of organization) 



where the parameter "content" is between 0 (i,e., only organization 
matters) and 1 (i.e., only content matters). 

The final parameter "persist" increases the valuation of each 
component of the benchmark version, to require that a threshold of 
improvement be exceeded before changes are adopted: 



(benchmark valuation) = (benchmark valuation) (1 + "persist"/100) 



B, Algorithms Used to Evaluate Alternative Versions 



The scores of topics are built up from the scores of components 
such as subtopics and pages* 

The score of any given page VAL(page) is the average of all 
submitted evaluations, optionally deleting the X% highest and 
lowest scores to decrease the sensitivity to outlier evaluations. 
The score of the set of pages ("PMAP") constituting the content of 
a topic is: 

VAL(PMAP) = (average VAL(page)) x (number of pages) A extensivity 
or 

VAL(PMAP) = (average VAL(page) ) A (l-ext. ) x (number of pages ) A ext. 

The value of a set of subtopics is then: 

VAL( subtopics) = 

(average VAL(PMAP)) x (number of subtopics) A {extensivity} 
or 

(average VAL(PMAP) ) A (l-ext. ) x (number of subtopics) A ext. 



The value of a topic can then be calculated as: 

VAL(topic) « ("content") x ( VAL( subtopics ) ) 

+ (1 - "content") x (VAL(SMAP)) 

where SMAP is a given arrangement of subtopics , and VAL(SMAP) is 
the average evaluation of that organization. 



5^ Estimation of User Evaluations 



Privatization Planner(tm) provides a user the ability to select and 
sort entries based on his or her own evaluation. If the user has 
not yet evaluated a particular entry, the system can provide an 
estimate derived from a regression analysis of entries which the 
user has evaluated versus other users' evaluations. 



The estimation method is: 



1. Formulate the two-dimensional evaluation array E Ai , where 
i is the user index (u being the index for the user whose 
evaluations will be estimated) and j is the observation 
index . 

2. Formulate the one-dimensional array HP^ as follows: 

W s = 1 + |E tt3 - E,|- 

if there is an actual observation for E ui , and 

W u j = 0 otherwise. 

In this expression, a is a user-specifiable parameter 
whose default value is 0. This weight function, which 
provides the ability to weight more heavily observations 
where the user's evaluation differed most from the 
average, can be replaced by other weight functions. 

3. Formulate the one-dimensional array W A 3 for each i ^ u 
as follows: 

= wr 4 if there is an actual observation for E Aj , 

W A 3 = 0 otherwise. 

This ensures that there is a non-zero weight only where 
there are actual observations for both users u and i. 

The preferred implementation is to already have summed 
the number of actual evaluations for each user, and to 
presort them by descending number, and then only consider 
the first X percentile according to processing power and 
response time constraints. 



4. Perform a regression of E uj vs. E Aj with weights W A 3 . 
The default functional form is linear as follows: 

A 

E uj = m A E Aj + b A , 

although other functional forms such as polynomial or 
logarithmic are possible. 

The preferred implementation is to first form two sums: 
"regression observations" = 5^W A V and 
"# predictions" = number of instances where there is 
no observation for user u (and therefore needing 
an estimate) and there is. an observation for user i 
(and therefore able to provide an estimate). 
Then, the regression analysis is, performed only against 
those users i for whom the two sums are in top Y and Z 
percentile respectively , or alternatively is not 
performed against those users i for whom those two sums 
are in the bottom Y and Z percentile respectively. 

5. The estimate for each observation j which lacks an actual 
evaluation by user u is found by: 

E = , where 



r A is the correlation coefficient for the selected . 
functional form regressing E uj vs. E 13 ; 

8 is a user-specifiable parameter, whose default is 1, 
able to modulate the weight of the correlation 
coefficients; 

y is a user-specifiable parameter, whose default is 1, 
able to modulate the significance of the sums of the 
weights of the observations used in the regression. 

Notes: 1) This approach reduces the severe multi- 
col linearity problems which would result from a 
multiple-user regression analysis. 

2) Other weight functions are possible. For example, 
the weight of the prediction of user i can be set to 
zero when user i and user u are anti-correlated (i.e., 
r A < 0) by replacing r A in the above formula with the 
term MAX(0,r A ). In addition, the user could restrict 
the regression analysis to a specified set of users. 
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Section 1* Background 



It is natural for individuals and groups to aspire to a clean 
environment and economic development for themselves and their 
progeny. These aspirations are evolving into two new human 
rights norms: the right to a safe environment and the right to 
development. At the same time, these dual aspirations are 
combining into a duty of states to pursue sustainable development 
under a new international public trust doctrine. 

The immediacy of this challenge is clear, as the human population 
grows past five billion individuals on a finite, irreplaceable 
planet. 

Unprecedented cooperation between academe, government and 
industry will be necessary to learn the science, develop the 
technology, train the leaders, formulate the policies, coalesce 
the support and commercialize the products and services necessary 
to achieve sustainable development. 

The Sustainable Development Server (tm) is intended to serve as a 
focal point to facilitate the necessary development and 
interaction. Participants can review, evaluate and contribute to 
structured information in an adaptive knowledge base specializing 
in sustainable development. The philosophy of this approach is 
that the combination of powerful yet friendly software 
technology, an interesting, useful and well-structured initial 
knowledge base, and a knowledgeable and motivated user community, 
will yield a "critical mass". In this case, dynamic positive 
feedback loops will lead to improvements in the software 
technology, expansion of the knowledge base, and growth of the 
user community. 



Section 2. The Conceptu al Development of Sustainable Development 



It is not enough to identify the problem. Even if the pursuit of 
sustainable development becomes acknowledged as a policy 
imperative by the leaders in academe, government and industry, 
this must be translated into specific choices and concrete 
actions. Sustainable development must evolve beyond a cliche 
into a mature, operational concept. 

One approach, following MIT economist Robert Solow, is to 
inventory all forms of capital and track whether they are 
increasing in the aggregate. From this perspective, a diminution 
in one form of capital can be compensated by an increase in 
another. For example, even economic development of part of a 
rainforest which was effectively invested in human capital 
through education could be consistent with sustainable 
development. 

This aggregate-capital conceptual structure is outlined in Figure 
1. Capital assets (and liabilities!) are categorized into non- 
human assets (biological, environmental and natural resources) 
and human social assets (human resources, intangible products and 
tangible products) . Assets (and liabilities) are subject to 
intra- and inter-category transfers by individuals and 
organizations. 

Policy instruments such as regulations (e.g., prescriptive, 
performance, taxation) or the establishment of bundles of 
property rights along with their transfer mechanisms (e.g., gift, 
sale, rent) affect the behavior of individuals and organizations. 

Taken together, sets of assets and associated policy instruments 
constitute portfolios. These portfolios can be associated with 
individuals, enterprises, countries, regions or the world. 

A central focus of sustainable development is the choice of 
technique to value and to aggregate such portfolios, taking into 
account appropriate constraints imposed by distributional equity 



Figure 1. Sustainable Development 
From the Perspective of Aggregate Capital 



Assets fand Liabilities^ 



Biological Resources 
Resources 

- plant kingdom 

- animal kingdom 

- ecosystems 

- biomes 



Non-Human Assets 
Environmental Assets 



- capacity to degrade, 
dilute or store 
harmful products 

- natural settings 



Natural 



- air 

- water 

- minerals 

- land 



Human R esources 
products 

- population 

- training 
informal 
health 
vocational 
elementary 
secondary 
university 
continuing 



Human Social Assets 
Intangible Products 



- architecture 

- art 

- government 

- knowledge 

- languages 

- law 

- literature 

- music 

- performance art 

- tedchnology 



Tangible 



-agriculture 
-armaments 
-consumer goods 
-conveyances 
-infrastructure 
-productive 
equipment 



Policy Instruments 

regulation (e.g., prescriptive, performance, taxation) 
establishment of bundles of property rights, along with 
mechanisms for their transfer (e.g., gift, sale, leasing, rent) 
alternative valuations of assets (and liabilities) 



Assets (and liabilities) are subject to intra- and inter-category 
transfers by individuals and organizations. These transfers are 
affected by the choice of policy instruments. Taken together, 
the assets (and liabilities) and policy instruments constitute a 
portfolio associated with individuals or groups. The valuation 
and aggregation of such portfolios, subject to appropriate equity 
constraints, is a central focus of sustainable development. 



Section 3. Sust ainable Development Server; (±.m\ 
A Collaborative Knowledge Base 



A collaborative knowledge base is the product of a knowledge 
building community which constructs patterns of knowledge through 
sociocultural activity, while renewing itself through ongoing 
apprenticeship. 1 Education has typically involved the assignment 
of tasks or the orchestration of a novice's development. 2 In 
contrast, a knowledge building community helps novices "formulate 
their own goals, do their own activating of prior knowledge, ask 
their own questions, direct their own inquiry, and do their own 
monitoring of comprehension." 3 In the development of the science 
and policies to further sustainable development, collaboration is 
mutually beneficial as the knowledge base grows cumulatively, if 
not exponentially. Therefore, it is essential for representatives 
from academe, government and industry to coalesce into an 
effective knowledge building community. 

A knowledge building community of environmental and policy 
analysts can be promoted by the Sustainable Development Server™, 
a collaborative knowledge base generator. It is initialized with 
a hierarchy of topics containing pages of information. This 
knowledge base is distributed by the system coordinator to 
knowledgeable and motivated users by diskette, or made available 
on an electronic network. Users can then evaluate and comment on 
its organization and content or propose changes. 

For example, the first menu of topics includes "Academic 
Programs", "Best Practices", "Bibliography", "Consortium 
Members", "Employment and Services", "Information Networks", and 
"Suggested Imporvements to the System". The user could choose the 
"Academic Programs" topic , select the "Massachusetts Institute 
of Technology" subtopic, and then explore the different course 
listings, departmental programs and research programs with an 
environmental aspect. 



x See M. Scardamalia, c. Bereiter, "An Architecture for 
Collaborative Knowledge Building" 2, in E. De Corte, M. Linn, H. 
Mandl, L. Verschaffel (eds.), "Computer-Based Learning Environments 
and Problem Solving", NATO-ASI Series F.: Computer and Systems 
Sciences (in press). 

2 M. Scardamalia, C. Bereiter, "Higher Levels of Agency for 
Children in Knowledge Building: A Challenge for the Design of New 
Knowledge Media", 1 (No. 1) Journal of Learning Sciences 37. 38-39 
(1991). ' 

3 Id. at 39. 



At this point the user has a variety of options before moving on 
to another topic. He or she can respond to questions embedded in 
the information pages (such as whether to be placed on a mailing 
list for additional information) . The user can also evaluate and 
comment on the presentation of the topic, and thereby influence 
whether or not it will be retained into the next generation. 
Another option is to insert proposed new pages of information or 
even additional related subtopics. The proposed additions can 
also contain embedded questions, and will also be subject to 
evaluation and comments. 

The system coordinator compiles all responses and makes comments 
availiable to the relevant authors for review. After either 
manually or algorithmically determining the "best" versions and 
alternates of the knowledge base from the evaluations provided by 
the analysts, the next generation is distributed and undergoes 
another cycle of review. 

Design choices reflect the objective to achieve a clean, simple 
and cost-effective system. While there is a login sequence to 
identify responders, security is provided by transmission of 
diskettes to and from known groups ineligible to sign with other 
users 1 ids. While proposed topics and pages of information are 
available to all users for review, comments are only made 
available to the relevant authors. This preserves the 
independence of future comments and simplifies processing, but at 
the expense of intellectual interaction. The algorithms to 
"score" the topics and pages of information are straightforward 
functions of quality and quantity, subject to parameter-tuning or 
even manual override in practice. Finally, pop-up windows for 
simultaneous topics, help screens or glossaries may be desirable. 



Section 4. Operation of th e Sustainable Development Server ff™) 



A. From the Perspective of an Individual User 

Each user is provided a diskette containing the executable module 
"sds.exe" , and a hierarchical data base of sustainable 
development information contained in directory "sds". The user 
first copies these onto disk when available, and then types: 

sds 

The system then prompts as follows: 

Enter disk drive for sds file [e.g., 'c:']: 

Enter directory of sds file [e.g., 'sds']: 

In each case, the suggested answers constitute an appropriate 
default. 



At this point, the program displays the top of the hierarchical 
"table of contents" in "page mode", and awaits user commands (see 
sections 5 and 6) . 

Upon completion of the user's review, the data base will include 
his or her evaluations and proposed changes. The user then copies 
the data base back to diskette and forwards it to the system 
coordinator for compilation and analysis. 

B. From the Pe rspective of the System Coordinpto-i; 

The job of the system coordinator can be parsed into a series of 
tasks: 



i) The current version of the executable program file and the 
hierarchical data base is distributed to a select set of interested 
and knowledgeable users. 

ii) The users explore those portions of the data base which are of 
relevance and interest to them. In the process, they have the 
ability to enter their opinions for the values of variables, to 
evaluate and . comment on topic layouts and page contents, and to 
pages 86 addltxons ' "Placements or deletions to topics and/or 

Note that the security system amounts to the transmission of the 
diskette to and from known users. The software supports the abilitv 
for each distributee to circulate the original diskette or a copl 
of it among additional users (who would have the same ability) . 



However, since all the users of a given physical diskette would 
have the ability to alter or override each other's responses, this 
should be limited to knowledgeable and interested persons in a 
position of privity to the original distributee. 

In addition, where the system is used in a "closed end 11 automatic 
optimization mode, where the evaluations of a known set of users 
determine the versions preserved into subsequent distribution 
cycles, if the distributee includes additional users then a single 
"optimal" representation of the distributee's entire group can be 
formulated. 

iii) The diskettes are returned to the system coordinator, who 
aggregates them by copying directories and files onto a disk 
partition, and then onto a composite diskette or diskettes. The 
composite diskette (s) are then redistributed for evaluation and 
comment. Note that if necessitated by the quantity of information, 
different subsets of the composite data base can be distributed to 
different users for this evaluation phase. 

iy) A single diskette is then prepared for each user, containing 
his or her own topic setup and page contents, in addition to all 
evaluations, comments and entries for values of variables. 

This user is then given an opportunity to make modifications based 
on that feedback, and return a new version to the system 
coordinator. 



v) The system coordinator again copies directories and files onto 
a disk partition, and then runs the following modules when 
available: 

— "vacuum", which cleans out all unused files and directories; 

"evaluate", an optional step which tags the nodes of the 
hierarchical data base with values calculated according to the 
scoring parameters and algorithms in the Appendix; 

— "select", which copies to diskette (s) several versions: the 
"optimal thread" through the hierarchical data base for each of the 
last N generations (with ids of Gl, GN) and all contributions 
from the H highest-scoring users in the current generation. 

vi) The selected versions are then distributed at the start of a 
new "generation", corresponding to step (i) . 

vii) For implementation on an electronic network physical 
distribution of diskettes is unnecessary, and standard security 
procedures for access and login would apply. 
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Section 5, User Commands Available in Topic Mode 

Topic mode displays and supports alteration of the hierarchical 
organization of topics covered in the system. It can be thought of 
as an interactive , hierarchical table of contents, 

A series of commands is available in topic mode: 

Topic 

Syntax: T or Txx 

where xx is between 0 and the number of available topics at this 
level in the hierarchy. Note that in this and subsequent commands, 
either capitals or the lower case is acceptable. 

This command allows a user to move about in the organizational 
hierarchy of topics. 

T steps up one level in the hierarchy by invoking the next higher 
topics. 

TO reverts to the top of the hierarchy by invoking the root topics. 

Txx selects the specified topic from among the displayed 
selections. 

Error conditions: 

If xx specifies an unavailable topic, the user is notified and 
prompted to try again. 



&d£ 

Syntax: A or Axx 

where xx is between 0 and the number of topics available at this 
level in the hierarchy. 

This command allows a user to add a topic at the current level in 
the hierarchy. 

A appends a new topic after existing topics. 

Axx adds a new topic before topic number xx, except "AO" is 
equivalent to "A M . 

After creating the new topic, the user is prompted to enter its 
heading . 

Error condition: 

1. If xx specifies an unavailable topic, the user is notified and 
prompted to try again. 



2. While one user may view another user's topic organization, 
modification of it is not allowed. 



Replace 
Syntax: Rxx 

where xx is between 1 and the number of topics available at this 
level . 

This command allows a user to replace a topic in the current level 
in the hierarchy. 

After deleting the current version of the topic, the user is 
prompted to enter the heading of the replacement version. 

Error conditions: 

1. If xx specifies an unavailable topic, the user is notified and 
prompted to try again. 

2. While one user may view another user's topic organization, 
modification of it is not allowed. 



Delete 
Syntax: Dxx 

where xx is between 1 and the number of topics available at this 
level. 

This command allows a user to delete a topic in the current level 
in the hierarchy. 

Error conditions: 

1. If xx specifies an unavailable topic, the user is notified and 
prompted to try again. 

2. While one user may view another user's topic organization, 
modification of it is not allowed. 



Heading 
Syntax: H 

This command allows a user to change the heading of the current * 
topic. 

The user is prompted to enter the new heading of the current topic. 
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Note: to change the heading of one of the subtopics available from 
the current topic, that topic must first be invoked with the 
"Topic" command before using the "Heading" command. While that 
topic could have been deleted without changing to it, its contents 
or "pages" of information would have been lost. 

Error condition: 

A user is not allowed to modify another user's topic. 



Eval 

Syntax: E 

This command allows a user to evaluate the organization of the 
current topic, and to enter any comment on it. 

The program first requests an evaluation as follows: 

Please evaluate this topic (1 = very poor, 5 = very good) : 

The user has the option to enter a number from 1 to 5, with 3 beina 
neutral . 3 

The program then requests any comment: 

Please enter any comment on this topic: 

The user then has the option to enter a comment, terminated by a 
"carriage return" or "enter" keystroke. 

Error condition: 

if ^Li?? 9 £?~ 0n US6r is in his or her own setu P' toe command 
is unavailable. 



Pace Mode 
Syntax: P 



This command allows the user to switch from topic mode to page 
mode. Topic mode is used to view or alter the organization or 
hierarchy of the information base, while page mote iTused f tc °vie£ 
hierarchy aCtUal contents ot a particular topic in the 



Syntax: U or Uid; 

where id corresponds to the character string identifying a 
particular user. 

If "U" is entered without an id, the system presents the id and 
name of each available user, providing an opportunity to select 
each in turn. 

If "U" is entered with an id, the system verifies the id is 
accessible and then displays the topics according to that user. 

If the id specified in the "U" command does not correspond to that 
of the logged-on user, he or she will be prevented from executing 
Add, Replace, Delete or Heading commands. 

On the other hand, if the id specified in the "U" command 
corresponds to that of the logged-on user, he or she will be given 
an opportunity to "adopt" the organization or contents, for the 
current topic, of the user previously being presented. 

The system first informs the logged-on user whether he or she 
already has a personally customized setup for the organization of 
the current topic. It then asks whether the logged-on user wishes 
to "adopt" as his or her own, and therefore accessible to future 
revision, the topic organization of the user previously being 
presented. 

The system then informs the logged-on user whether he or she 
already has a personally customized setup for the page layout and 
contents of the current topic. It then asks whether the logged-on 
user wishes to "adopt" as his or her own, and therefore accessible 
to future revision, the page layout and contents of the user 
previously being presented. 



Quit 

Syntax: Q 

This command gracefully terminates operation of the program, 
returning the user to the operating system. 



A 



Section 6. User Commands Available in Paae Mode 



Page mode displays and supports alteration of the contents of pages 
of information relevant to the current topic within the 
hierarchical data base. The topic can be thought of as part of the 
table of contents, while the pages are the actual information so 
addressed. 

A series of commands is available in page mode: 



Page 

Syntax: P or Pxx 

where xx is between 0 and the number of available pages at this 
level in the hierarchy. 

P increments the page counter to display the contents of the next 
page, and is invalid if the last page is already being displayed. 

Pxx displays the contents of the specified page, except that PO has 
the same effect as P. 

Error conditions: 

If xx specifies an unavailable page, the user is notified and 
prompted to try again. 



Add. Re place. Delete. Eval 

These commands are exactly analogous in form and function to their 
usage in topic mode, except that in page mode they refer to the 
appropriate page associated with the current topic • 



Topic Mode 
Syntax: T 

This command allows the user to switch from page mode to topic 
mode. Topic mode is used to view or alter the organization or 
hierarchy of the information base, while page mode is used to view 
or alter the actual contents of a particular topic in the 



User 



This command allows the logged-on user , who is accessing the page 
contents of a second user's (or his or her own) topic setup as 
determined by the latest User command in topic mode, to view the 



entries of still a third user for the values of variables embedded 
in the page. 

While the User command in page mode does not invoke a different 
user's organization or contents, the form and usage are exactly 
analogous to that in topic mode. 



Values 
Syntax: V 



Each page can contain a series of variables embedded within the 
text, as demarcated by a pair of braces "{...}" . This command 
allows each logged- on user to enter his or her own judgment as to 
the best values for those variables. 

The program will highlight each variable in turn, and prompt the 
user for a new entry. The user need not enter a value for all or 
any variables. On the other hand, if a user's judgment should 
change, additional subsequent entries supersede earlier ones. 

Quit 

This command is equivalent in form and function to its usage in 
topic mode. 



Appendix: Knowledge Base Adaptation 



A. Parameters Used to Evaluate Alternative Versions 

The scoring algorithms rely on the evaluation of topics and pages. 
Three parameters are used in the process of transforming the set of 
evaluations into composite scores. 



The first parameter relates to the issue of quality versus 
quantity. A purely "intensive" scoring system would score ten high 
quality pages of Information equally to one such page. On the other 
hand, a purely "extensive" scoring system would score two mediocre 
pages twice as high as one. 

On the assumption that the value of the data base is a combination 
of its quality and quantity, the parameter "extensivity" achieves 
this as follows: 

value = (quality score) x (measure of quantity) A { extensivity} 

where both the quality score and the measure of quantity are 
greater than or equal to one, and the extensivity parameter is in 
the range from 0 (i.e., only quality matters) to 1 (i.e., the score 
is proportional to quantity) . 

Parameter "content" fixes relative weights of organization and 
content: 

topic value=( "content" )x (evaluation of aggregated subtopic content) 
+ (1 - "content") x (evaluation of organization) 



where the parameter "content" is between 0 (i.e., only organization 
matters) and 1 (i.e., only content matters). 

The final parameter "persist" increases the valuation of each 
component of the benchmark version, to require that a threshold of 
improvement be exceeded before changes are adopted: 



(benchmark valuation) = (benchmark valuation) (1 + "persist "/100) 



B. Algorithms Used to Evaluate Alternative Versions 

The scores of topics are built up from the scores of components 
such as subtopics and pages. 

The score of any given page [VAL(page)] is the average of all 
submitted evaluations. The score of the set of pages ("PMAP") 
constituting the content of a topic is:} 

VAL(PMAP) = (average VAL(page)) x (number of pages) ^extensivity 

The value of a set of subtopics is then: 
VAL( subtopics) = 
(average VAL(PMAP)) x (number of subtopics) A {extensivity) 

The value of a topic can then be calculated as: 

VAL(topic) - ("content") x (VAL(subtopics) ) 

+ (1 - "content") x (VAL(SMAP) ) 

where SMAP is a given arrangement of subtopics , and VAL(SMAP) is 
the average evaluation of that organization. 
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Sustainable Development Server (tin) page 1 of 2 Mon Aug 30 22:31:10 1993 

Sustainable Development Server (tm) Version 1.0 
You are sys mgr, looking at the primary version, with default values 

Sustainable Development Server(tm), copyright William J. Hartnett, 1993 

This collaborative knowledge base is designed to support the pursuit 

of sustainable development. It includes a hierarchical table of contents 

of "topics", with information contained in corresponding "pages". 

The initial knowledge base will include information on academic programs, 
best practices, bibliography, employment, information networks, and 
suggestions for improvements to the system. 

[... Look to the bottom line for command options. For example, to see 
the next page type "P" ; and to switch to topic mode type "T" . . . ] 



Enter command: P 

Page Add Replace Delete Values Eval Topic User Quit 
2 1-2 1-2 1-2 mode [id] 



Sustainable Development Server (tm) page 2 of 2 Mon Aug 30 22:31:17 1993 

Sustainable Development Server (tm) Version 1.0 
You are sys mgr, looking at tlie primary version, with default values 

This collaborative knowledge base is designed to be systematically updated. 

The software supports the ability of users to evaluate and comment upon 
individual screens and pages. Users can also propose additions, 
replacements and deletions of individual screens and pages. 

User evaluations determine which parts of the collaborative knowledge base 
are sufficiently "adaptive" to survive into the next generation. 

Proposed changes are included as alternatives which compete with the 
new primary version. 



[...To see what topics are available, switch to topic mode by typing "T"...] 
Enter command: T 

Page Add Replace Delete Values Eval Topic User Quit 
1-2 1-2 1-2 1-2 n Sde [id] 
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Sustainable Development Server (tm) Mon Aug 30 22:35:27 1993 

Sustainable Development Server (tm) Version 1.0 

You are sys mgr, looking at the primary version, with default values 

T for next higher topics; TO for root topics; P for page contents. 

« 

Tl Academic Programs 

T2 Best Practices 

T3 Bibliography 

T4 Consortium Members 

T5 Employment and Services 

T6 Information Networks 

T7 Suggested Improvements to the System 



Enter command: Ti 

Topic Add Replace Delete Heading Eval Page User Quit 
0-7 1-7 1-7 1-7 mode [id] 



Sustainable Development Server (tm) Mon Aug 30 22:52:26 1993 

Academic Programs 

~ You are sys mgr, looking at the primary version, with default values 

T for next higher topics; TO for root topics; P for page contents. 

Tl California Institute of Technology 
T2 Massachusetts Institute of Technology 



Enter command: P 



Topic Add Replace Delete Heading Eval Page User Quit 
0-2 1-2 1-2 1-2 mode [id] 
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Sustainable Development Server (tm) page 1 of 1 Mon Aug 30 22:53:02 1993 

Academic Programs 

You are sys mgr, looking at the primary version, with default values 

A wide range of academic programs supports the pursuit of sustainable 
development. These can be categorized as degree programs and research 
programs. 

Degree programs are available at the undergraduate and graduate levels, 
in departments ranging from law, public policy or political science to 
science or engineering. 

Academic research programs focus faculty, staff and student resources 
on different issues relating to sustainable development. 



Enter command: T, T2 

Page Add Replace Delete Values Eval Topic User Quit 
1-1 1-11-1 1-1 mode [id] 



Sustainable Development Server (tm) Mon Aug 30 22:53:15 1993 

Massachusetts Institute of Technology 

Vou are sys mgr, looking at the primary version, with default values 

T for next higher topics; TO for root topics; P for page contents. 

Tl MIT Environmental Course Listings 

T2 MIT Departmental Programs with Environmental Aspects 
T3 MIT Research Programs Involving the Environment 



Enter command: Tl 



Topic Add Replace Delete Heading Eval Page User Quit 
0-3 1-3 1-3 1-3 node [id] 
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Sustainable Development Server (tin) • Mon Aug 30 22:58:06 1993 

HIT Environmental Course Listings 

——-You are sys mgr, looking at the primary version, with default values — 

T for next higher topics; TO for root topics; P for page contents. 4 

Tl 1.725J Chemicals in the Environment: Fate and Transport 
T2 1.811J Environmental Law: Pollution Control 

T3 1.812J Regulation of Chemical Toxins, Radiation, and Biotechnology 

T4 1.972 Environmental Restoration Engineering 

T5 3.576J Law, Technology, and Public Policy 

T6 10 .72 J Chemicals in the Environment: Sources and Control 

T7 10.805J Technology, Law, and the Working Environment 

T8 n. 328 J Science and Technology in International Affairs 

T9 11.334 Environmental Pollution: Problems, Solutions, and Policy 

T10 11.361 Environmental Policy and Regulation 

Til 11.362 Environmental Management 

T12 11 .3 63 J Chemicals in the Environment: Policy and Management 
T13 11.364 International Environmental Negotiation 
T14 12.300 Environmental Chemistry and Climate Change 
T15 17.301/2 Science, Technology and Public Policy 
Enter command: TJL,P 

Topic Add Replace Delete Heading Eval Page User Quit 
0-18 1-18 1-18 1-18 mode [id] 



Sustainable Development Server (tm) page 1 of 1 Mon Aug 30 22:58:18 1993 

1.811J Environmental Law: Pollution Control 
— You are sys mgr, looking at the primary version, with default values 

Reviews and analyzes Federal and state regulation of air and water pollution 
and hazardous wastes. Emphasizes use of legal mechanisms and alternative 
approaches (such as economic incentives) to control pollution. Focuses on 
the major Federal legislation, the underlying administrative system, and 
the common law in analyzing the goals of pollution control, economic 
consequences, and the role of the courts. Discusses both classical 
pollutants and toxic industrial chemicals. Also provides an introduction 
to basic legal skills. j 

N.A. Ashford, C.C. Caldart 



Enter command: Tj T / Tj Tz 

Page Add Replace Delete Values Eval Topic User Quit 
1-1 1-11-1 1-1 mode [id] 
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Sustainable Development Server(tm) Mon Aug 30 23:06:55 1993 

MIT Departmental Programs with Environmental Aspects 

You are sys mgr, looking at the primary version, with default values 

T for next higher topics; TO for root topics; P for page contents. 

Tl Civil and Environmental Engineering 

T2 Earth and Atmospheric Sciences 

T3 Division of Toxicology 

T4 Urban Studies and Planning 

T5 School of Engineering 

T6 School of Science 

T7 Sloan School of Management 

T8 Woods Hole/MIT Joint Program in Oceanography and Oceanographic Engineering 
T9 MIT Technology and Policy Program 



Enter command: T% ? 

Topic Add Replace Delete Heading Eval Page User Quit 
0-91-91-9 1-9 mode [id] 



Sustainable Development Server (tm) page 1 of 1 Mon Aug 30 23:07:24 1993 

MIT Technology and Policy Program 
You are sys mgr, looking at the primary version, with default values 

The Technology and Policy Program is an interdisciplinary graduate program 
designed for "engineers and scientists with a difference" , professionals with 
a strong technical foundation who also have the ability to deal with important 
social concerns. Masters and doctoral students in the program work on problems 
covering the wide range of technical fields available at MIT, including 
environmental studies. 

The curriculum has two parallel tracks, one with a focus on engineering and the 
physical sciences and one with a focus on the social sciences. The curricula 
of both tracks include three subjects in policy analysis and three subjects in 
an integrated core selected by the student and his or her advisor. Thesis 
topics are often based on research projects that include both technical and 
policy components. Typical topics in environmental studies include priority 
setting and enforcement in hazardous waste remediation, water conservation and 
pricing, and the economic and environmental impacts of alternative energy 
policies. Faculty comes from Engineering, Political Science and Urban Studies. 
Enter command : r, to, 

Page Add Replace Delete Values Eval Topic User Quit 
1-1 1-11-1 1-1 mode [id] 
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Sustainable Development Server (tm) Mon Aug 30 23:09:14 1993 

Bibliography 

You are sys mgr, looking at the primary version, with default values 

T for next higher topics; TO for root topics; p for page contents. 

Tl Author Listings 

T2 Solow Literature Search (By Author) 
T3 Right to Development 
T4 Structured Bibliography 



Enter command: T7 ; ? > f~i ^ 

Topic Add Replace Delete Heading Eval Page User Quit 
0-4 1-4 1-4 1-4 mode [id] 



Sustainable Development Server (tm) Mon Aug 30 23:19:04 1993 

Author Listings 

----- You are sys mgr, looking at the primary version, with default values 

T for next higher topics; TO for root topics; P for page contents. 

T211 Meadows, D. , Smart Development, Not Dumb Growth 
T212 Mendes, C, Fight for the forest. 

T213 Merchant, c, Radical ecology: the search for a livable world 

Hit 2J^ S6ll A R *i Econo * ic development and the environment: a comparison of sus 
T215 Mmkow, D. ; Murphy-Dunning C, Assault on Papua New Guinea. 
T216 Miyamoto, J., Tackling Environmental Issues in Companies 

niB ^Si^'J^l'^SS"? ■»*»*■■« Attempting to Deal Simultaneously wi, 
T218 Morandini, N. , La cumbre de Rio fue un rugido de raton. 

llll M°ttfa°uras, A., Competitive Equilibria and Sustainable Growth in a Life-cyc 
T220 Mumtaz, S.; Durr-e-Nayab, Management Arrangements of the Chaprote Forest an 

Hl\ 2 USU ' h' E m? no S ia , e anblante - (Economics and Environment. With English sum 
T222 Myers, N. , The Environmental Basis of Sustainable Development 
T223 Newall, J., The Challenge of Competitiveness 

lilt S^v laise S' J * ? Ho , eller ' p " *or Econ. Coop, and Development. Dept. of 

Enter coSd: TZ.T?P J "' Soeteman ' F * ? Pari *h' » Magrath, W., Regi 

Topic Add Replace Delete Heading Eval Page User Quit 
0-356 1-356 1-356 1-356 node [id] 
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Sustainable Development Server(tm) page 1 of 2 Mon Aug 30 23:39:55 1993 

Meadows, D. , Smart Development, Not Dumb Growth 
Vou are sys mgr, looking at the primary version, with default values 



Fulll Citation: 



Meadows, D. , "Smart Development, Not Dumb Growth", 95(6) Technology Review 68-69 
(Aug/Sep 1992) . 



Enter command: P 

Page Add Replace Delete Values Eval Topic User Quit 
1- 2 1-2 1-2 1-2 mode [id] 



Sustainable Development Server(tm) page 2 of 2 Mon Aug 30 23:40:02 1993 

Meadows, D. , Smart Development, Not Dumb Growth 
You are sys j„ grf Poking at ^ pr i nary version, with default values 

Abstract (ABI): The recent US history of stimulating economic growth at any cost 
is precisely what has created the current difficulties. Smart development build 
s °" a , re 9 ion 's unique skills and resources and encourages durable local busines 
s, while dumb growth entices a big corporation, which exerts control from outsid 
e, drains profits back outside, undercuts local manufacturers, and lays off hund 
reds of people without warning. Dumb growth also disregards many infrastructure 
investments because they do not pay off visibly enough or soon enough. Drawing a 
distinction between sustainable development and unsustainable growth does not m 
ean being anti-economic; it means being practical and creating an economy that d 
oes not delude itself with booms that create their own busts or with drawinq dow 
n and polluting the resources of the earth upon which all economic activity depe 



Enter command: T t TO 

Page Add Replace Delete Values Eval Topic User Quit 
1-2 1-2 1-2 1-2 tt ode [id] 
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Sustainable Development Server (tm) Mon Aug 30 23:41:14 1993 

Sustainable Development Server (tm) Version 1.0 * 

You are sys mgr, looking at the primary version, with default values — 

T for next higher topics; TO for root topics; P for page contents. 

Tl Academic Programs 

T2 Best Practices 

T3 Bibliography 

T4 Consortium Members 

T5 Employment and Services 

T6 Information Networks 

T7 Suggested Improvements to the System 



Enter command: 

Topic Add Replace Delete Heading Eval Page User Quit 
0-7 1-7 1-7 1-7 mode [id] 



Sustainable Development Server(tm) Mon Aug 30 23:41:25 1993 

Consortium Members 

-—You are sys mgr, looking at the primary version, with default values 

T for next higher topics; TO for root topics; P for page contents. 



Tl Academe 
T2 Government 
T3 Industry 

T4 International Agencies 

T5 Non-Governmental Agencies (NGOs) 



Enter command: 

Topic Add Replace Delete Heading Eval Page User Quit 
0-5 1-5 1-5 1-5 mode [id] 



WOW/10637 



t"l"l/US!U/ 11139/ 



Sustainable Development Server (tm) Mon Aug 30 23:41:35 1993 

Employment and Services 

You are sys ragr, looking at the primary version, with default values 

T for next higher topics; TO for root topics; P for page contents. 

Tl Consultancies 

T2 Law Firms 

T3 Positions Available 



Enter command: T, T6 

Topic Add Replace Delete Heading Eval Page User Quit 
0-3 1-3 1-3 1-3 mode [id] 
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Information Networks 

Vou are sys mgr, looking at the primary version, with default values 

T for next higher topics; TO for root topics; P for page contents. 

Tl On-line Computer Networks 
T2 Off-line Computer Networks 
T3 Other Information Networks 



Enter command: $ 

Topic Add Replace Delete Heading Eval Page User Quit 
0-3 1-3 1-3 1-3 mode [id] 



CLAIMS 

1. A method of operating a digital computer to support the 
execution of transactions to buy and sell assets maintained in 
portfolios of diverse asset owners, comprising the steps of: 

collecting for execution portfolio transactions 
submitted by portfolio owners; 

aggregating the collected transactions into a single 
transaction data base; and 

consummating the market transactions aggregated in the 
transaction data base, by matching buy and sell transactions of 
substantially but not necessarily equal parameters. 

2. The method of claim 1 further including the step of 
updating the portfolios to account for the consummated 
transactions. 

3. The method of claim 1 further including the step of 
transmitting the consummated market transactions to financial 
intermediaries specified by particular portfolio owners. 

4. The method of claim 1 wherein the step of consummating 
comprises the steps of: 

establishing an estimated asset price; 
successively approximating the asset price until 

convergence is reached between buy and sell transactions. 

5. A method to aggregate private rights to state-owned 
enterprises into a "Stock Market Unit" which achieves 



immediateprivatization without the need to value enterprises, 
comprising the steps of: 

specifying an interval over which all enterprises 
of a particular category will be included in the Stock Market 
Unit; 

for each individual who is to share in the ownership 
of said enterprises, establishing on a mass storage unit of a 
digital computer system an asset ownership file; and 

crediting to each said asset ownership file one share 
in each such enterprise. 

6. A computer-implemented method of creating a liquid market 
in annuity instruments comprising the steps of : 

defining in a computer memory standardized actuarial 

tables; 

operating the computer to match offered annuity 
instruments with bid annuity instruments according to 
characteristics specified by particular bidders and offerors; 
and 

calculating and assigning as the price of such matched 
instruments the implcit interest rate in association with a 
particular standardized actuarial table. 

7. A computerized method of operating a market system for the 
service of exercising delegated investment authority over a 



portfolio, comprising the steps of: 

in a computer memory, building a file identifying 
delegatees qualified to exercise investment authority over 
portfolios; 

operating the computer to accept bids for the services 
of delegatees and offers of the services of delegatees wherein 
the compensation of the delegatee may be specified as either 
a percentage of assets to be traded or a percentage of total 
return; 

operating the computer to clear the market by 
determining those delegatee remunerations which satisfy the 
greatest quantity of delegations subject to maximum constraints 
by delegatee. 

8. A computerized method of polled shareholder voting on 
corporate resolutions, comprising the steps of: 

specifying to the computrer a threshhold above which a 
shareholder is considered large; 

specifying to the- computer a number of small 
shareholders to sample; 

operating the computer to generate a list of corporate 
shareholders before whom the corporate resolution should be 
placed, including each large shareholder and a statistical sample 
of small shareholders. 



9. A method of operating a computerized knowledge data base 
which evolves based on user evaluations and proposed 
contributions, comprising the steps of: 

operating the computer to receive from a user proposed 
contributions to the adaptive knowledge base; 

providing a user the ability to evaluate the 
organization and contents of the knowledge base, including new 
proposed contributions of other users; 

selecting those portions of the knowledge base to 
preserve as a function of evaluations. 

10. A method of operating a computerized data base which 
provides access to data base entries based on evaluations of said 
entries by any user or users, comprising the steps of: 

associating entries with user evaluations of said 
entries; and 

providing a user the ability to key access to entries 
according to the evaluations of any specified user or users. 

11. A method of operating a computerized data base which 
provides a user access to entries therein based on estimates of 
the user's own evaluations, comprising the steps of: 

correlating the user's past actual evaluations of 



entries with evaluations of those entries by other users; 

using those correlations, estimating the user's 
evaluations in the for an entry for which the user has not 
entered an actual evaluation. 

12. A method of operating a computerized data base which is 
distributed by segment to users based on their expressions of 
interest in different components of the data base, comprising the 
steps of: 

providing the user the capability to hierarchically 
tag portions of the data base with an indicator of interest; 

providing the user the capability to specify the 
quantity of information from the data base to be received in 
response to a query; 

probabilistically selecting portions of the data base 
for distribution as a function of interest level. 

13. A method of operating a computerized data base by which a 
user can define his own structure of keyword access, comprising 
the steps of: 

providing the user the capability to specify new 
keywords according to a boolean pattern of words or phrases 
contained in an entry; and 

providing the user the capability to override this 
default definition for specific entries in the data base. 



14. A method of operating a computerized data base which 
provides a gateway to other data bases or access to other program 
modules, comprising the steps of: 

identifying as a selection alternative at a particular 
location in the data base a gateway or program module; and 

providing the user the capability to store the current 
context of the data base, invoke the specified gateway or 
program module, and subsequently resume data base operation. 

15. A method comprised of any combination of the methods of 
claims 1 through 14 wherein the data base is an adaptive 
knowledge base. 

16. A method comprised of any combination of the methods of 
claims 1 through 13 in which an adaptive knowledge base is used 
to interface to a simulated or actual computerized marketplace. 

17. A method comprised of any combination of the methods of 
claims 1 through 16 in which assets are distributed to a large 
number of owners. 
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Enterprise leadership prepares Privatization Business Plan (PBP) 
including: selective pasport update, claimed physical facilities, 
organization census, demonopolization goal, in addition to 
stock compensation plan for board, management and workers. 
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Privatization Board Review of PBP: disapprove (with reasons), 
negotiate or approve; resolve inter-enterprise conflicts; 
establish effective privatization date. 



Effective privatization date 



Start of stock compensation plan 
Periodic financial reporting requirements 



Enterprise restructuring and spin-offs. 



Privatization Board review of enterprise application 

for certification of demonopolization: disapprove (with reasons), 

negotiate or approve; establish effective demonopolization date. 



^ E ffective de mnnopolization date 



Vesting of compensation stock 
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'Research and Analysis 

i \ 

Privatisation Planner™ 



Privatisation Planner™ | 



Establish property rights^-** 



Formulate incomes policyj 
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Structure privatisation sequence 



Privatisation Business Plans 
Effective Privatisation Pate | 
Demonopolisation Date | 



Establish oversight agency 



Customise Privatigel^i^T - 



Select assets to support j 



Select transactions to support 



Choose parameter values 
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Portfolio owners and delegates submit transactions 
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Processing centers generate Transaction Data Base 



Central computer processing 

Generate reinvestment transactions! * 



Establish valid delegations^— ""^""^ 2 *29 
Select between alternative transactionsT** 

133 



Calculate clearing prices] 
Transmit results to financial institutionST"^^^ 
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Support enterprise shareholder votes'! 



U— Support auctions of other state property 
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Vbudget/kn^3> 

^ : ^"T"^ 

<|equ enc e ofeve ng> < ^echo8lovagg > (^Tportfolio eaxriM» 

! 1 

i ' 

<^Poland^> <Tajc portfolio assets 




Rest of world ) ^Transaction^«^> 
South Africa"*} f Arbitrage revenue' 
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LOCAL 



REGIONAL 



CENTRAL 



|XACT|-*Q/y 
C7-> |XAcf]->g/<7^ 



> |XACT[-»°//3 



XACTj 



j=7-> lXACTh g/g- , ^ 
Q-» |XACf1 ->g/<r 



?} 



-> warning report 



ADB Auction DB — ^ 

CDB Citixen DB 

CHIDB Charitable Institution DB 

EDB Enterprise DB 

FIDB Financial Institution DB 

FORNDB Foreign Investor DB 

6DB Government DB 

PBDB Privatisation Board DB 

TDB Testamentary DB 



' (sotted and comprehensive) 
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Fig. 4 



9 



1 DQRFGEN I 



Generate delegatee order file. 



( PORT ( 



*| PASSi]m^^ Estimate asset prices assuming aD delegation offers 

aboTe delegatee-specified minima are consummated. 
Update XDB with reLnrestment transactions. 



EPRISE I &Tii*Ali 



PRICES 




|PASS3i *-^5 

sL 



Estimate asset rallies in order to ralue 
delegation offers and lending offers. 



iDELCOMPl 
I o ftp f us 
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» lPASS3 



Lending Reports 
Borrowing Upda tes 1 

J, 

IXACTl XACT: Update XDB. 

^ DELCOMP: Calculate delegatee compensation thresholds. 

Estimate asset priees using final delegations. 
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I PRICES V 
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EPRISE 
PRICES 



dispose l effi 



Use price estimate #2 to decide whether to 

inToke ELSE transactions. Calculate final asset prices. 



Execute transactions, calculate delegatee compensation, 
update XDB, generate DF. 



Sort disposition file. Prepare tapes/diskettes/reports 
for transmittal to financial institutions. 
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_ rie xp explains avanapie commands 
x TlfltaraBt level in topic 



eject 



page from laser printer 

Keyword definition or invocationT 



lapel tfle current topic 



Map current context 
.w/j Name the current topic 




v 



w 



X 



ur-aer ini^er ann-gnr 



Jj Page: s witch to page mode /display p age x 



Replace topic or page 

simulate PrWatize 1 (tm) marketplace 



✓ Topic; switch to topic mode or display topic x 
User; select information of specif ied user 




Values; specify values embedded in page" 



Write a message to a specif ied user 

exit customize/Help/Map/Order/Simulate/Write 
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